[csswg-drafts] [css-syntax] Excluding '!' and '; ' in <general-enclosed>? (#3594)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-syntax] Excluding '!' and ';' in <general-enclosed>? ==
(migrated from the mailing list)

**Simon Sapin said:**

> 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.

---------------

**Florian Rivoal said:**

> > 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.

---------------

**Simon Sapin said:**

> I don’t think there is a reason. The main difference is that @supports 
> is based on CSS 2 chapter 4, whereas MQ4 is based on CSS Syntax 3.

-------------

**Tab Atkins said:**

> Yup, that's it. The change isn't intentional, it just falls out of the
> the easiest way to define it in each of the two grammar forms.
> 
> I could rename `<any-value>` to `<property-value>` and make a new
> `<any-value>` that is less restrictive, if you think it's valuable.

------------------

**Simon Sapin said:**

> That sounds like as good a way to do it as any, but I do think we should 
> fix unintentional arbitrary syntax restrictions.

---------------

**Tab Atkins said:**

> Done. `<any-value>` and `<declaration-value>` are now defined in Syntax,
> and specs that previously used `<any-value>` have been updated as
> necessary.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3594 using your GitHub account

Received on Saturday, 2 February 2019 00:04:56 UTC