[csswg-drafts] [css-syntax-3] How to specify grammar for rules? (#11241)

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

== [css-syntax-3] How to specify grammar for rules? ==
eab6ac4 removed this paragraph from [CSS Syntax 3 ยง Defining Grammars for Rules and Other Values](https://drafts.csswg.org/css-syntax-3/#rule-defs):

  > Non-terminals representing the entire grammar of an at-rule are written as an `@` character followed by the at-rule's name, between `<` and `>`, e.g. `<@media>` to represent the `@media` rule.

<details>
<summary>Now the section only defines the non-terminals representing rule block contents. The grammar for rules is currently specified either in prose or using a rule notation that has never been specified and thus may be ambiguous.</summary>

1. `@rule { <block-contents> }` could either represent a list of tokens, an at-keyword followed by a simple block, or a single rule object. While a conforming CSS parser can parse a function either as a list of tokens or a single function component value, against a functional notation, it can only parse a rule as a list of tokens. However, [`@page`](https://drafts.csswg.org/css-page-3/#syntax-page-selector) must be parsed as a list of component values against its rule notation, which seems problematic for its block contents (already reported in [#7140](https://github.com/w3c/csswg-drafts/issues/7140)).

2. [#8156](https://github.com/w3c/csswg-drafts/issues/8156) reported `<rule> = <rule-name> { <block-contents> }` as an invalid rule value definition before the above paragraph was removed: `<rule>` was not starting with `@`. Defining a rule notation using a non-terminal for its name seems fragile, unless clearly specified and restricted, as it cannot produce just any value. Relatedly, [#10558](https://github.com/w3c/csswg-drafts/issues/10558) discusses accepting `name ()` as a valid functional notation and consequently, accepting (consuming) optional whitespaces between a function name and `(` in the input (during tokenization), to allow defining custom functions (mixins) with `<dashed-function> = <dashed-ident> (<declaration-value>#)`.

</details>

In #8156 and #9114, rule definition tables were mentioned. They allow for richer grammar definitions and ensure that the required definition data is provided. They might also have drawbacks.

All three solutions could be inclusive but I think it might be useful for spec authors to clarify how they *can* or *must* define the grammar of a rule.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 19 November 2024 08:43:36 UTC