Re: media queries syntax

2009/10/16 Yves Lafon <ylafon@w3.org>:
> On Thu, 15 Oct 2009, Bert Bos wrote:
>
>> On Thursday 15 October 2009, Yves Lafon wrote:
>>>
>>> Hi,
>>> I am looking at the media-queries CR document [1], form a CSS
>>> Validator standpoint, and I am wondering why the syntax of expression
>>> is '(' .. ')' instead of using a function name like 'feature(' ...
>>> ')'.
>>
>> I think it was never considered. So the question would more properly be
>> the opposite: why is a functional notation better?
>>
>> There is no absolute answer, but here are a couple of considerations:
>>
>>  - Media Queries are used in CSS, but not only there. They also occur
>>   in HTML (in the LINK and STYLE elements) and in XML (in the
>>   xml-stylesheet PI). They are expressly designed to be used in yet
>>   other places that we don't know about. Parentheses are a common
>>   vocabulary that works almost anywhere.
>>
>>  - You may think that "feature()" is more readable, I think it just
>>   adds redundancy and makes many expressions too long to fit nicely on
>>   one line. :-)
>>
>>  - Parentheses are normal delimiters in CSS. They appear in the grammar
>>   alongside functional notations, and together with the similar square
>>   brackets. The grammar wasn't changed in any way to accommodate
>>   Media Queries.
>
> No, they are not. And the grammar _was_ changed to accomodate media
> queries...
>
> http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915/#syntax
>
> expression
>  : '(' S* media_feature S* [':' S* expr]? ')' S*
>  ;
>
> Trying to parse (foo) with a CSS21 aprser based on CSS21 syntax will fail.

While instead it is legally allowed by the core syntax, which says:
at-rule: ATKEYWORD S* any* [ block | ';' S* ];
any: [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
              | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
              | DASHMATCH | ':' | FUNCTION S* any* ')'
              | '(' S* any* ')' | '[' S* any* ']' ] S*;
so (foo) matches the "any" production (going '(' IDENT ')' ), and
@media (any) is good core syntax, but ignored by forward compatible
parsing rules for UA that don't implement the "foo" media feature.

>>> handling in other part of the spec for errors like
>>> color: rgb (1,2,3); (instead of rgb(1,2,3);)
>>
>> But the validator already handles that, as far as I know. "rgb(" is one
>> token, while "rgb (" is a pair of tokens. You get an error message that
>> rgb isn't a valid color and that the rest of the value cannot be
>> parsed.
>
> Well, if you change the grammar and add the possibility of having '(...)' a
> valid construct, then the rest of the value _can_ be parsed, meaning that
> all the error handling has to be changed.

It is not a valid construct (at the grammar point) and nothing has to
be changed, because the sequence of tokens for
rgb (255,255,255 ) in css2 core grammar
IDENT S ( NUMBER DELIM NUMBER DELIM NUMBER )
and it is still in css3-syntax (a module cannot change the core
syntax, it would break backward compatibility)
while the <color> production in css3-color is:
<color> --> FUNCTION NUMBER DELIM NUMBER DELIM NUMBER )
<color> --> FUNCTION NUMBER DELIM NUMBER DELIM NUMBER DELIM NUMBER )
<color> --> HASH
<color> --> IDENT

with the additional semantic restriction that FUNCTION must be "rgb(",
"hsl(" for the first version, "rgba(" or "hsla(" for the second, all
DELIMS must be ",", numbers must be within the 0-255 range (0-1 for
the forth number in the second production), HASH must match a valid
color subgrammar and IDENT must be either "transparent",
"currentColor" or a named color.

This means that "rgb (255,255,255)" cannot be a good color, no matter
whether there are parts of the grammar (Appendix G, amended by css3
modules) that allow ( and ) tokens.

The trick to understand this: think of the core grammar instead of the
versioned one.

>> Or do you mean that you want to add specific heuristics so that the
>> error message can say that there is probably a space too many?
>
> Heuristics are in the todo list, but not the reason of this message :)
>
>>>
>>> plus 'feature(...)' seems more readable than '(..)' (but that's
>>> subjective
>>>
>>> :) ).
>>
>> Indeed it is. :-)
>
> I told you ;)
>
>>
>>>
>>> [1] http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915/
>>
>>
>>
>> Bert
>>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>
>

Giovanni

Received on Friday, 16 October 2009 12:24:53 UTC