Re: [css-variables] Using $foo as the syntax for variables

I like the "$foo" proposal for several reasons, but clarity and extensibility seem like the major considerations:

Besides the obvious advantages of simplicity and unified declaration/usage syntaxes, I consider the separation of variables from functions to be a strong positive. Variables and functions serve different purposes - one stores information and the other acts on it. In order to allow an expansion of both features in the future, each one deserves a syntax best suited to it's purpose.

Clarity is not always about unification, sometimes it is about difference. CSS should avoid adding new syntax structure where existing structures suffice - but it is an even bigger mistake to re-use the same syntax for different purposes. I would much rather learn a new syntax when given a new feature, than have existing syntaxes muddled with too many meanings.

Sass in particular has already fought this battle, re-using available CSS syntax before realizing it was a mistake. We've already learned this lesson, don't repeat our mistakes in an attempt to protect us.

I know there's a fear of "programmery" syntaxes in CSS, but I think the fear is misguided. The simplicity of CSS, combined with the increased demands of web design, have led to nearly unreadable documents. I find it much easier to teach a beginning designer to use meaningful mixins and variables, before diving into the complex hacks and workarounds required by "simple" CSS. Abstraction exists to help us manage complexity, and languages such as Sass have already paved the way. We need to take the best of what is out there, and not reject solutions due to a mythical programmer/designer division.

Don't worry about Sass users. We have survived plenty of syntax changes, as the language has become more robust, clear, and concise. CSS variables cover the main use-case that Sass variables were intended for (and more use-cases on top of that). If there really are cases that would be handled better in pre-processing, I'm sure the community will find a new way to handle those concerns. It is not the job of the w3c to take care of the Sass syntax, but you do have the opportunity to learn from it.

Cheers,
Eric Meyer

(@eriiicam, not @meyerweb)


On Monday, May 21, 2012 at 3:30 PM, Tab Atkins Jr. wrote: 
> Right now, the Variables draft makes variable names be simple idents,
> and uses the var() function to reference them. This was *one* option
> for using variables, which I chose on the hope that it would make it
> easier for the group to accept the draft.
> 
> Another possibility is to use a $ glyph as a prefix. This was
> suggested by several people in the WG after I presented the current
> Variables draft, and it matches the way SASS does variables. Chris
> Eppstein, one of the SASS devs, has been telling me repeatedly that
> the $foo syntax will be easier for devs.
> 
> I was afraid of switching over because I already know that we want to
> extend the basic usage of variables to, for example, allow providing
> default values. However, Chris pointed out that this isn't
> incompatible with the $foo syntax. You could use ordinary variables
> without special abilities like "color: $foo;" but access the extended
> abilities with functions, like "color: var-default($foo, blue);".
> This seems acceptable to me.
> 
> So, since some members of the WG already expressed a desire to see
> Variables switch over to this syntax, are there any strong objections?
> 
> Some further details - to handle $foo in the syntax, we'll either need
> to add a VAR token to the grammar (defined identically to HASH but
> with the $ character instead of #) or accept that variables show up in
> the tokenizer as a $ DELIM followed by an IDENT. The latter is
> suboptimal, though - it allows comments between the $ and the foo,
> which sucks, and it means we have to deal with the "first character of
> an IDENT" detail, despite there being no ambiguity (HASH gets to avoid
> all that and just use "nmchar+").
> 
> A similar change would be necessary for the property name if we want
> to accept the proposal to match the syntax of declaration and use.
> While I wasn't wild about having the var() function show up as a
> property name, I like the syntax of "$foo: red;".
> 
> These grammar changes are backwards-compatible - the
> forward-compatible parsing rules will interpret them as errors and
> throw away everything up to the end of the declaration, as normal for
> syntax errors.
> 
> ~TJ