Re: CSS Variables Draft Proposal

On 2/15/11 1:24 PM, Tab Atkins Jr. wrote:
> 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.

Sounds reasonable to me.

> 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.)

That's not at all true.  For example, if I have these styles:

   div { font-family: Times; }
   div { font-family: something-nonexistent; }

then a <div> will get styled with whatever the UA fallback font for 
"something-nonexistent" is, not with Times.

If, on the other hand, I have:

   div { font-family: Times; }
   div { font-family: $something-nonexistent; }

then as far as I can tell the div should end up with the Times font.  In 
particular, a lot more work has to be done on @var additions/removals in 
terms of redoing the cascade, etc, than has to be done for @font-face 
additions/removals.  That's a cost we'll need to pay if we want 
undefined variables to "fall back" to other rules instead of just the 
initial value for the property or something.

-Boris

Received on Tuesday, 15 February 2011 18:33:47 UTC