- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 15 Feb 2011 10:39:57 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: David Singer <singer@apple.com>, www-style list <www-style@w3.org>
On Tue, Feb 15, 2011 at 10:32 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/15/11 1:24 PM, Tab Atkins Jr. wrote:
>> 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.
Ah, you're right. Sorry about that.
I hadn't considered making invalid variables just knock the
declaration back to an initial value. I doubt that would be a huge
difference in usability. Is that substantially easier from an
implementation standpoint?
~TJ
Received on Tuesday, 15 February 2011 18:40:51 UTC