Re: [css3-conditional] Resolving issues

On Thursday 2012-09-27 09:35 -0700, Tab Atkins Jr. wrote:
> On Thu, Sep 27, 2012 at 9:32 AM, Simon Sapin <> 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.)


π„ž   L. David Baron                  𝄂
𝄒   Mozilla                    𝄂

Received on Tuesday, 9 October 2012 23:48:20 UTC