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

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

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Tue, 22 May 2012 19:04:00 +0400
To: Tab Atkins Jr. <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-Id: <473931337699040@web20g.yandex.ru>
I personally very like $-based syntax (compared with functional syntax for reading variable value). $-based syntax is compact, intuitive and consistent with variables' syntax in other popular languages like PHP.

One of reasons to use variables in CSS is to make declarations more compact/readable. Functional syntax is a priori _less_ compact/readable than $-based.

So, choosing functional syntax could result in that authors would use it rather less often then if a more appropriate syntax would be chosen.

As for default values, their potential use seems to be much more rare than using regular values of variables, so it's perfectly OK for me too to have a CSS function for default-value purpose _specifically_ while providing more usable $-syntax for _most common_ usecase.

The only potential issue with using _only_ $-syntax for _both_ defining and using variables, is cases where author wish to use a variable for property _name_, not value. For example:

    /* Defining 'bp' variable as alias for 'background-position'. */
    :root {var-bp: background-position; }

    /* Using compact $bp as property name instead of long 'background-position' */
    .foo {$bp: center; }

So maybe it makes sense to keep var-prefixed syntax for _defining_ variables while using $-syntax for using _values_ of already defined variables. This completely removes ambiguity like "whether declaration containing $-prefixed property name is variable _definition_, or the $-prefixed property name should be replaced with value of a variable defined before".

22.05.2012, 01:30, "Tab Atkins Jr." <jackalmage@gmail.com>:
> 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 15:04:51 UTC

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