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:39:57 -0800
Message-ID: <AANLkTinWZOsrLYPUOLYTYxCg+tC_ynu51yUnZPqNQH6t@mail.gmail.com>
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?

Received on Tuesday, 15 February 2011 18:40:51 UTC

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