W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: Brian Kardell <bkardell@gmail.com>
Date: Mon, 21 May 2012 22:31:47 -0400
Message-ID: <CADC=+jfn=xtiTg5mKiXWAqj2HbDhaA3OWJNNWHa3GeNyCOZhTw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
It would also mean that it would be weird at best to use $ as the subject
token in selectors level 4, something which has been proposed.

FWIW:  Personally, I really liked the version in the draft.  I found it
powerful and in keeping with the rest of CSS (including not requiring
changes to the forward compatible parsing).  Referencing by $ does read
pretty nicely and its a standard syntax in lots of kinds of expressions.
I am less wild about the declaration, but I made similar comments when Tab
first shared the draft I think...

SASS currently has the advantage of a wide user base, so maybe there is
something to the idea that it is easier for some subset of current SASS
users... and I am all for the idea of proving things out and allowing
authors choices to help shape future standards from the ground up.  It
would be nice if the two could compete so we could see what would happen,
but the exisiting apis would make that challenging.

I don't think either is particularly hard to learn and I'm not sure how big
the number of people is who would have trouble with the version that
doesn't look like SASS.

However... if it looks kind of (or even exactly, declaration and all)  like
SASS, but there isn't perfect parity with what SASS does (calculation as
well I mean)... Isn't that actually potentially more confusing for the same
group of people?

Just a thought.

On May 21, 2012 8:13 PM, "Tab Atkins Jr." <jackalmage@gmail.com> 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
Received on Tuesday, 22 May 2012 02:32:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC