W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: CSS Variables Draft Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 15 Feb 2011 10:24:41 -0800
Message-ID: <AANLkTi=YM8SCL-JqxkJGoRhSPjPSV1PzgLi_JOFyRaZb@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
On Mon, Feb 14, 2011 at 7:33 PM, David Singer <singer@apple.com> wrote:
> On Feb 15, 2011, at 4:46 , Tab Atkins Jr. wrote:
>>> What is the expected behavior of this markup:
>>> div {
>>>  color: red;
>>>  color: $foo;
>>>  color: $bar;
>>> }
>>> in a browser that supports variables if $foo and $bar are both not defined?
>>>  If $foo then suddenly becomes defined?  If $bar then becomes defined?
>> This is defined in the draft now.  An undefined variable computes to
>> an always-invalid value.  CSS then proceeds as normal.  So, in this
>> case, the color is red at first (as both of the latter two rules
>> contain invalid values and so are ignored).  When $foo becomes
>> defined, assuming it's defined to a valid color value, then the color
>> becomes $foo's value.  Same when $bar is defined.
> are there already places where something that has a syntax error can become something that does not, as a result of some other change of state?  I.e. you're saying that the other two color rules can't be discarded at parse time (which is what you might expect from a syntax error) as they may become non-syntax errors later...

Sorry, in an email I'm composing in response to Boris' latest message
I've revised my position.  My previous position was informed by a
mistaken understanding of how the CSSOM worked.  Given my new
understanding, the above example would work much more simply:

Only the final 'color' declaration is honored, the previous two are
thrown away at parse time, just like normal.  If $bar isn't defined,
then the value is invalid, leaving the declaration block with no valid
'color' declaration at all.  If $bar is then, later, defined with a
valid color value, the rule will start working.  Defining $foo will
have no effect, since the rule that referenced $foo was thrown away at
parse time.

This should now perfectly match the behavior of, say, referring to a
non-existent font family which is defined in a @font-face later in the
document.  (Well, almost - unknown font families are first matched
against local fonts before being ignored, while undefined vars are
just invalid from the start.)

Received on Tuesday, 15 February 2011 18:25:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC