Re: [csswg-drafts] [css-fonts-4] `<font-feature-value-block>` is defined with an invalid syntax (#8156)

FWIW, I think production rules are not the best solution to define CSS rules. There are not often new CSS rules so sticking to defining them in prose may be the best solution. However, the current in-between situation does not seem ideal to me.

You do not parse CSS rules like declaration values, by matching against a production. You resolve the definition from the name of the rule and the context, then you match the prelude and/or the block contents against this definition.

Also, production rules cannot define which properties the rule accepts in its block, and how they interact with the cascade.

Definition tables are not perfect but they seem more appropriate. And `w3c/reffy` can easily extract their data.

<details>
  <summary>If rule definition tables are an option...</summary>

In definition tables, properties/descriptors are identified with a `Name` field value. But qualified rules have no name, and some at-rules have alternative or context-sensitive syntaxes (`@layer`, style rules, some group rules).

Style rules may be identified with `<@style>`: one may see `div { & {} }` as a shorthand for `@style div { @nested-style & {} }`. Rules with alternative or context-sensitive syntaxes would also require a unique type identifier: `<@layer-block>`, `<@layer-statement>`, `<@nested-media>`, etc. This seems like a downside but it also applies to production rules.

I think it is easier to define relations between rules with a `Rules` field value than with a `For` field value (like descriptors). It would be confusing for top-level rules and I think it represents a higher maintenance cost. It may be fine to mix both but they should not be defined at the same time, ie. for the parent and child rules.

Some examples...

```
Name:    <@color-profile>
Prelude: [<dashed-ident> \| device-cmyk]
Block:   <declaration-list>
```

Similarly for `@counter-style`, `@font-face`, `@font-palette-values`, `@property`, etc.

---

```
Name:    <@keyframes>
Prelude: <keyframes-name>
Block:   <qualified-rule-list>
Rules:   <@keyframe>
```

```
Name:       <@keyframe>
Prelude:    <keyframe-selector>#
Block:      <declaration-list>
Properties: All excluding animation-* but including animation-timing-function
Cascade:    No, !important is invalid.
```

---

```
Name:    <@font-feature-values>
Prelude: <family-name>#
Block:   <declaration-rule-list>
Rules:   Font feature value rules.
```

```
Name:  <@annotation>
Block: <declaration-list>
```

Similarly for other font feature value rules.

---

```
Name:    <@style>
Prelude: <selector-list>
Block:   <block-contents>
Rules:   Nested style/group rules
```

I think the block contents should be ideally defined with `<declaration-rule-list>`, which should allow declarations and rules, instead of declarations and at-rules.

```
Name:       <@nested-style>
Prelude:    <relative-selector-list>
Block:      <block-contents>
Rules:      Nested style/group rules
Properties: All
```

Similarly for `<@nested-container>`, `<@nested-layer-block>`, `<@nested-media>`, etc.

```
Name:    <@container>
Prelude: <container-condition>
Block:   <rule-list>
Rules:   All rules allowed at the top-level of a stylesheet, and not otherwise restricted.
```

Similarly for `<@layer-block>`, `<@layer-statement>`, `<@media>`, etc.

```
Name:    <@scope>
Prelude: [(<scope-start>)]? [to (<scope-end>)]?
Block:   <rule-list>
Rules:   Nested style rules and all rules allowed at the top-level of a stylesheet and not otherwise restricted.
```
</details>

-- 
GitHub Notification of comment by cdoublev
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8156#issuecomment-1736658679 using your GitHub account


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

Received on Wednesday, 27 September 2023 04:33:41 UTC