W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[css3-conditional] Review of the new grammar for @supports

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 02 Nov 2012 22:31:41 +0100
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.wm50q3sxf5de51@riboaru-nashiosamus-imac-2.local>
I've checked the new version of @supports, and although I agree with the  
intent, I've found a few things to nitpick about.

The spec says:

> to avoid confusion caused by precedence rules, the syntax does not allow  
> ‘and’, ‘or’, and ‘not’ operators to be mixed without a layer of  
> parentheses.

This is only true of the specialized grammar, not of the generic one,  
which allows 'and' and 'or' without nesting. More importantly, there  
doesn't seem to be any guidance on how to evaluate such an expression.

The only instruction I can find on how to evaluate things that match the  
generic grammar but not the specialized one is this:

> anything else If a parenthesized expression does not match
>  the result of one of the grammar productions
>  above, it must not be treated as invalid, but
>  rather simply be false for the purpose of
>  support conditions.

However, the following construction is "anything else", matches the loose  
grammar, but is not a parenthesized expression:

   (foo:bar) and (bar:baz) or (baz:bang)

It seems to me that the current wording does not indicate whether this  
should be treated as invalid or as false. Example 8 suggests invalid, but  
I cannot find a clear justification in the normative text.

This could be fixed by adding the following sentence to the "anything  
else" paragraph: "If a non-parenthesized expression does not match the  
result of one of the grammar productions above, it must be treated as  
invalid". Alternatively, the loose grammar could be changed to:

   : NOT S* '(' any+ ')' S* |
     '(' any+ ')' S* (  OR S* any+ )* |
     '(' any+ ')' S* (  AND S* any+ )*

It should be noted that with both solutions, "(foo) and (bar) or (baz)" is  
invalid while "((foo) and (bar) or (baz))" is false. I am only moderately  
happy about that, but I am not sure there is a good way around it if we  
want the forward compatibility offered by allowing anything inside  

On a side note, each of the 3 parts of example 8 has an extra closing  
parenthesis, which should be removed.

  - Florian
Received on Friday, 2 November 2012 21:32:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC