Re: [css3-conditional] Resolving issues

On 10/09/2012 04:47 PM, L. David Baron wrote:
> 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.

If we're treating unknown functions as false, why not also treat malformed
declarations as false?

e.g., why should
   @supports not unknown(@foo) { ... }
   @supports not (@foo) { ... }
be treated differently?

> 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.

At-risk or not, we're asking implementations to change here. If we're
unsure, then it should be marked as an open issue, so that implementers
know it's undecided.

I wouldn't want us to publish changes, have implementations update in
response, and later decide it was the wrong decision, just because we
didn't want to take the time up front to be sure.


Received on Friday, 12 October 2012 02:28:20 UTC