- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 27 Sep 2012 09:35:23 -0700
- 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 UTC