Re: [css3-conditional] Resolving issues

On Fri, 12 Oct 2012 04:27:51 +0200, fantasai  
<fantasai.lists@inkedblade.net> wrote:

> 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 <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.
>  If we're treating unknown functions as false, why not also treat  
> malformed
> declarations as false?
>  e.g., why should
>   @supports not unknown(@foo) { ... }
> and
>   @supports not (@foo) { ... }
> be treated differently?

I don't think there is any particular difficulty in terms of implementation
in making that change if we deem it desirable.

Whether it is a good idea or not is harder to evaluate. I was initially
uncomfortable with it, essentially for the reasons stated by fantasai.

On further thought, @supports is designed to treat as false things is can
parse but not understand, so deciding that functional notation should
be parseable even if you don't understand it doesn't sound too bad.

But even then, I am still somewhat skeptical. According to
http://www.w3.org/TR/CSS21/syndata.html#tokenization,
   FUNCTION S* [any|unused]* ')'
cannot match
   ruleset( p{foo:bar} )
unless you use the 'unused' production, which is documented
as something that will never be used for anything be error
recovery.

If we don't add this "| FUNCTION S* [any|unused]* ')'" to the
supports_declaration_condition production in this level,
nothing prevents us from adding "| 'block' '(' S* block ')'" in
a future level, but if we do add "| FUNCTION S* [any|unused]* ')'",
introducing things that look like a functional notation but don't
actually match this production later risks being pretty awkward.

  - Florian

Received on Friday, 12 October 2012 12:25:30 UTC