Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-syntax-3] How to specify grammar for rules? #11241

Open
cdoublev opened this issue Nov 19, 2024 · 0 comments
Open

[css-syntax-3] How to specify grammar for rules? #11241

cdoublev opened this issue Nov 19, 2024 · 0 comments

Comments

@cdoublev
Copy link
Collaborator

eab6ac4 removed this paragraph from CSS Syntax 3 § Defining Grammars for Rules and Other Values:

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.

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.
  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 must be parsed as a list of component values against its rule notation, which seems problematic for its block contents (already reported in #7140).

  2. #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 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>#).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant