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

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

Received on Monday, 21 May 2012 21:31:44 UTC