Re: [css-variables] Different syntax for variable definition and use

On Sun, Feb 17, 2013 at 10:56 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 17/02/2013 06:24, Jens O. Meiert a écrit :
>> It seems CSS variables remain based on var-foo/var(foo). I stick to my
>> argument that this is counter-intuitive.
>>
>> I don’t intend to argue against the current syntax forever, but I
>> still like to ask, did we explore other syntactical options, like e.g.
>> the following?
>>
>> foo { [var]: 20 }
>> bar { line-height: [var]px }
>>
>> Generally, could someone—no offense, but maybe not Tab :)—explain why
>> we are left with what we have now? I find it hard to believe that we
>> have no options that are more usable, i.e. user-friendly.
>
> The main argument is not changing the syntax for declarations:
>
>    <name> whitespace* ':' <value>
>
> … where <value> can be anything, but <name> can only be a single ident
> token.
>
> I don’t think that the Core Grammar is really frozen (we’ve accepted
> multiple changes already, however minor.) But there is some resistance in
> changing such a fundamental concept as what is a "declaration".
>
> Having worked on multiple parser implementations, I personally feel that,
> although non-trivial, such a change would be completely doable. There is no
> web-compat issue either: the error recovery rules ensure that old UAs drop
> declarations they don’t understand. It might be worth it if we have a vastly
> superior syntax proposal.

Correct on all counts.  The parser isn't frozen, but neither are we
willing to make changes without corresponding benefits.  I find Jens'
suggested notation hideous, personally. ^_^

Also, having the get and set notations identical will, I believe, lead
to persistent confusion among new authors that we can avoid by having
them slightly different.  I received some feedback early on in
Variables asking how someone could use a variable as a property name,
as in, storing "background-color" or something in a variable and using
it to set that property.  If the two syntaxes look identical, I think
people will sometimes assume that they can actually do such a thing.
(Example 8 covers this.)

A further downside of a syntax like Jens' is demonstrated by his very
example - he used "line-height: [var]px;", building a dimension out of
a variable and an identifier.  We explicitly rejected this kind of
construction very early on - we want variables to operate on the level
of tokens, not text, so implementations don't have to preserve source
text just to parse a variable.  The way to turn a raw number into a
pixel length is with calc().  The current syntax, where var() is a
function, does not lend itself very well to accidentally being used
incorrectly in this way - people already know that functions don't
"combine" with other things. (Again, Example 8.)

> There is some agreement that the "var" prefix/function name could be
> changed, though.

It's possible, sure, but none of the alternatives have been any better
than the status quo (individual WG members might like one or the other
slightly better, but the WG as a whole hasn't found any to be
obviously superior), and I like the current name, for reasons I've
given previously.

~TJ

Received on Sunday, 17 February 2013 20:52:01 UTC