- From: L. David Baron <dbaron@dbaron.org>
- Date: Tue, 9 Oct 2012 19:47:53 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Simon Sapin <simon.sapin@kozea.fr>, www-style@w3.org
On Thursday 2012-09-27 09:35 -0700, Tab Atkins Jr. wrote: > 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. This works for me. I think we should mark it at-risk, though, given the lateness of the addition; I'd like the ability to reconsider without having to go through another last call. (We could also consider introducing a single function, to test whether a function is supported. Thus supports-function(supports-function) would be true and supports-function() with any other argument would be false.) -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla http://www.mozilla.org/ π
Received on Tuesday, 9 October 2012 23:48:20 UTC