W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: [css3-conditional] Resolving issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 27 Sep 2012 09:35:23 -0700
Message-ID: <CAAWBYDC+JpHeqvtNbt8v5quUU5pv=n_x0dh-uVKNn46mqq10Ww@mail.gmail.com>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: www-style@w3.org
On Thu, Sep 27, 2012 at 9:32 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 27/09/2012 18:19, Tab Atkins Jr. a écrit :
>> However, I can see the value in being able to explicitly test for
>> "does the browser understand this".  So, I may be amenable to just
>> treating the function itself as false, and letting negations work as
>> normal.
>
> Yes this is what I meant. A function the browser does not know (that is, any
> function in level 1) would be false, not indeterminate.
>
> But now I see why indeterminate could be more meaningful: a browser might
> not understand selector(foo) in @supports, but actually support the selector
> foo. But I still think that "not selector(foo)" should be true in this case,
> as there is no harm in using a fallback that avoids a feature even though
> the feature is supported.

That's a good argument.  Okay, I give.

Hey, rest of the WG (especially dbaron)!  What do you think about this:

Amend the grammar of supports_condition to also accept arbitrary
functions, and treat unknown functions (right now, all of them) as
false.

~TJ
Received on Thursday, 27 September 2012 16:36:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:00 GMT