Re: [css-mediaqueries] whitespace handling

Le 08/07/2013 11:35, Florian Rivoal a écrit :
> On Wed, 03 Jul 2013 12:55:16 +0200, Simon Sapin <simon.sapin@exyr.org>
> wrote:
>
>> Le 03/07/2013 06:57, fantasai a écrit :
>>> Parens and Escapes
>>> ------------------
>>>
>>>      - RESOLVED: MQ requires white-space on both sides of a parenthesis
>>
>> I believe that this is an incorrect summary of the change we discussed.
>>
>> The change is rather to require whitespace on both sides of the 'and'
>> keyword (and 'or', when and if we add it) when that would separate form
>> the "outside" of a parenthesis. That is:
>>
>>       ) and
>>
>>       and (
>>
>> Note that 'and(', being a FUNCTION token, was already invalid. But using
>> S+ rather than S* in the grammar avoids incorrectly suggesting that it
>> is valid. This change only affects 'and/**/(', as well as ')and' for
>> symmetry.
>
> An errata was published for this. I don't think it is right, so I'd like
> to reopen this.
>
> http://www.w3.org/Style/2012/REC-mediaqueries-20120619-errata.html
>
> This does almost what Simon said, but not quite: it requires spaces on
> both sides of "and" when used between media features, but only requires
> space after "and", not before, if and is after a media type. So this is
> allowed:
>
> @media screen/**/and (min-width: 100px) { .... }
>
> This that what we want? I would think not, this isn't very consistent with
> the fact that we have disallowed the following 2:  I
>
> @media (min-height: 100px)/**/and (min-width: 100px) { .... }
> @supports (height: 100px)/**/and (width: 100px) { .... }
>
> In addition to this, in @supports, NOT is followed by S+, not S*. As long
> as we are harmonizing, I suggest we do the same in media queries as well.
>
> Based on all that, I suggest we change the grammar (im MQ3 errata and MQ4)
> to this:
>
> media_query
>      : [ONLY | NOT]? S+ media_type S* [S AND S+ expression ]*
>        | expression [ S AND S+ expression ]*
>      ;
>
> Thoughts?


TL;DR: I don’t think it matters. Let’s take Florian’s proposal.


The issue we want to fix is having grammar like this:

    some-keyword S* '('

Which suggest that 'and(' is valid, while it’s not. Whitespace is 
required there in practice[1], so let’s write the grammar that way.

[1] That is, without the and/**/( trick that no-one will write outside 
of test cases.


This much fixes the issue. We also require whitespace before 'and' and 
'or' in @supports because symmetry is pleasant, but there is no real 
issue there because ')and' is not a FUNCTION or other special token.

@supports syntax is nice in that is has parentheses everywhere. MQs are 
a bit more funky so it’s not obvious where to require whitespace or not, 
but I don’t think it really matters. Let’s take Florian’s proposal and 
move on.

-- 
Simon Sapin

Received on Monday, 8 July 2013 11:17:10 UTC