This syntax is clearly preferable, but I think you knew that or you wouldn't have written it :)
I'm guessing the justification for the existence of the awkward var(varname) version is so that you can also have the parent-var(varname) notation.
I do think it's interesting how variables are scoped to dom nodes. Is there any reason it cannot be optional though, so if you omit it, it defaults to global?
I'm guessing the argument against, is that this requires too much of a change to CSS parsers, as it doesn't follow the standard form of <selector> { <properties> }. If that's really the reason it seems a bit of a shame though :/
I disagree that it is preferable, but that is debatable.
I say that in part for the reasons you mention, but also because it seems to me that quite a lot of people think that "$header-color" means "substitute the value of the header-color variable here" regardless of which side it is on. I think there is probably a happy middle ground where you achieve all of the goodness (looks like CSS, follows existing core grammar, shows the property nature, uses $ in familiar ways, etc). Not sure what it is, but probably something like:
I'm guessing the justification for the existence of the awkward var(varname) version is so that you can also have the parent-var(varname) notation.
I do think it's interesting how variables are scoped to dom nodes. Is there any reason it cannot be optional though, so if you omit it, it defaults to global?
$header-color: #06c; h1 { background-color: $header-color; }
I'm guessing the argument against, is that this requires too much of a change to CSS parsers, as it doesn't follow the standard form of <selector> { <properties> }. If that's really the reason it seems a bit of a shame though :/