Re: [css3-conditional] Resolving issues

On Thu, Sep 27, 2012 at 12:37 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 26/09/2012 19:33, Tab Atkins Jr. a écrit :
>> I agree that it's strange, but you simply*don't know*  whether it
>>
>> should be true or not.  My suggested solution is kinda similar to
>> NaN-poisoning, where once a NaN is introduced, it remains NaN until
>> you do something special with it.  This just wipes out the entire
>> unknown clause.
>
> I see the comparison, but I still believe we should not do this. For
> example:
>
> @supports foo(bar) { /* The new-and-shiny thing */ }
> @supports not foo(bar) { /* The almost-as-good CSS 2.1 fallback */ }
>
> The expectation here is that one of the two at-rules will apply.

But which one?  And what happens when, after the browser updates to
understand the new syntax, it flips?

The problem is that an unknown function *is not false*.  It's
indeterminate.  The negation of indeterminate is still indeterminate.
If we're being strict, the indeterminancy would infect AND and OR as
well, at least when there's not another clause that shortcircuits (a
false clause in AND, or a true clause in OR).  (However, I don't think
that's necessary - we can just treat it like false in these two
situations.)  When we return to the top level, if we're still looking
at an indeterminate result, I think the only reasonable answer is to
treat it as false, for safety, same as we would if this were just a
syntax error (which it effectively is, as long as the browser doesn't
recognize it).

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.

~TJ

Received on Thursday, 27 September 2012 16:20:08 UTC