- 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