Support CSS variables

CSS Variables introduces the <any-value> production, and Sass should support it.

This production introduces some serious questions about how Sass should parse it. It’s general enough to allow practically any string, which means that treating it as a normal property would break CSS compatibility. For example, var-foo: 1 +; is valid CSS, but currently Sass would fail to parse it. Fundamentally, we need to decide what balance to strike between compatibility, programmability, and user expectations. Here are several options:

1. The most compatible option would be to parse it exactly as specified in CSS and make no changes. For example, var-foo: $var would emit var-foo: $var literally, without replacing $var with its Sass value. This would make it impossible to assign variable values programmatically, though, as well as seriously violating user expectations.
2. The most programmable option and the option that would be least surprising to users would be to parse these as any other property. This would be a much larger break with CSS compatibility than we’ve done before, though, which itself violates the user’s expectation that all CSS is valid SCSS.
3. We could meet somewhere in the middle by allowing the use of #{} and possibly a single variable in <any-value> productions. This violates both compatibility, since $var is a valid CSS value that a user’s JavaScript might theoretically use, and user expectations, since e.g. var-foo: $var1, $var2, $var3 won’t work as expected. However, it will support most valid CSS and will allow variables to be created with mixins, albeit possibly with an ugly intermediate variable.
4. We could try to parse the value as a plain SassScript value, and if it fails to parse treat it as an unparsed. This would mean that any syntax errors would be difficult to track down, and poses more serious compatibility issues than option 3, since var-foo: 1 + 2 will be treated very differently in Sass than in raw CSS.

I’m not sure what the best option is. If I had to choose now, I’d probably lean towards option 3, but I don’t really like any of them.

[nazar-pc]

Guys, this should be top priority thing. Since you’re declaring full CSS compatibility you’re lying already. Moreover, since Polymer 1.0 uses custom CSS mixins, it doesn’t seem to be possible to write in SCSS at all:

--some-mixin : {
    font-size   : 10px;
    font-weight : bold;
};

Code above whould be compiled to exactly the same thing. It seems that check for -- prefix should be simple enough to implement, and if -- prefix found - leave it as is on current level.

[Draccoz]

I’ve read briefly all the above and still miss 1 use case. What if developer creates a SASS mixin to be used inside of SASS, but then will want to export that to be used outside (as CSS mixin). Ideally that would look like:

@mixin my-mixin {
  ...
}

:host {
  --my-mixin: {
    @include my-mixin;
  }
}

Sadly, none of the above would work, while this would be used a lot (I was actually in need of such thing myself). Any ideas if that will be possible and eventually when?