- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 15 Feb 2011 13:32:42 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: David Singer <singer@apple.com>, www-style list <www-style@w3.org>
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