- From: Florian Rivoal <florian@rivoal.net>
- Date: Mon, 23 Mar 2015 21:22:33 +0100
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style list <www-style@w3.org>
> On 23 Mar 2015, at 19:44, Simon Sapin <simon.sapin@exyr.org> wrote:
>
> The MQ4 ED currently uses <any-value> in its grammar:
>
>> <general-enclosed> = [ <function-token> | ( ] <any-value>* )
>
> and refers to css-variables, which defines it:
>
>> The <any-value> production matches any sequence of one or more
>> tokens, so long as the sequence does not contain <bad-string-token>,
>> <bad-url-token>, unmatched <)-token>, <]-token>, or <}-token>, or
>> top-level <semicolon-token> tokens or <delim-token> tokens with a
>> value of "!".
>
>
> First of all, since <any-value> is already "one or more" tokens, so the repetition in `<any-value>*` could be replaced with `<any-value>?`.
>
>
> Some tokens are excluded:
>
> A. bad-string, bad-url, unmatched ), ], or }. These always represent parse errors.
>
> B. Top-level ';'. This is so that '@support (--a: b; c) {}' doesn’t parse as a custom property with value 'b; c', which could not be represented in a style rule.
>
> C. Top-level '!'. This is to allow future extensions similar to !important to the property declaration syntax.
>
>
> A. makes sense for <general-enclosed> (or anything similarly open-ended) but B. and C. seem arbitrary there, the reasons for these restrictions just don’t apply.
>
> Note that the @supports grammar has a similar general-enclosed grammar production, but refers to CSS 2 to define it and so has the equivalent of A. but not B. or C.
Tab's the one how added this, so I'll let him answer as to whether there's a justification for B and C in this context.
As for me, I would much rather avoid accepting different syntaxes in @support and @media, so we should have a single definition of general enclosed (in css-conditional?) and have both specs use it.
If there is actually a reason for these two to be different, then we should use a different name than general enclosed for one of them.
- Florian
Received on Monday, 23 March 2015 20:22:59 UTC