[css-syntax] Excluding '!' and ';' in <general-enclosed>?

[tabatkins]

(migrated from the mailing list)

Simon Sapin said:

The MQ4 ED currently uses 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.