I understand the reasoning, but this new syntax is still kind of verbose and ugly. I think one of the reasons Sass has been so successful is that it is elegant. It adds a lot of functionality to CSS, but does so in a way that feels very much at home. This new syntax doesn't feels very elegant and it doesn't feel at home with current CSS syntax.

If I'd done what everyone keeps saying I should have done and just used $foo, then Sass would have gotten angry at me, because we'd be sharing syntax for different features. We already tweaked CSS a little to avoid that in another case (when specifying grid line names in Grid, you surround the names with []; it was originally (), but Sass asked us to change it because they use that for their list syntax).

We could only have used $foo if we hewed very close to Sass's functionality - global macros that operate at the stylesheet's lexical level. That wasn't what we wanted to do, though, either at the time (considering only the variables use-case) or looking forward (to the use of custom properties as the generic "inject info into your page via the CSS engine", a la data attributes for HTML).

By avoiding global macros, we also get context sensitivity - we can actually offer APIs for this stuff that are smarter than "here's the string you set". When we add custom pseudoclasses, custom media queries, etc they'll all get their own useful APIs. Sass is stuck with string manipulation, because you can use a Sass var anywhere, so it's impossible to infer anything about it.

Read the linked post. Css variables are nothing like macros like sass's `$foo` and css might support macros with sass's `$foo` syntax in future.

I read the article, that's why I commented because "might support something in future" that probably never happens, is what I related to XML based formats design decisions go wrong. Argh, but thanks for misunderstanding and downvotings.