CSS at rules have unexpected descriptors

[romainmenke]

For example in css-conditional-5.json:

    {
      "name": "@container",
      "prose": "The @container rule is a conditional group rule whose condition contains a container query, which is a boolean combination of container size queries and/or container style queries. Style declarations within the <block-contents> block of an @container rule are filtered by its condition to only match when the container query is true for their element’s query container.",
      "href": "https://drafts.csswg.org/css-conditional-5/#at-ruledef-container",
      "descriptors": [
        {
          "name": "width",
          "href": "https://drafts.csswg.org/css-conditional-5/#descdef-container-width",
          "for": "@container",
          "value": "<length>",
          "type": "range"
        },

https://drafts.csswg.org/css-conditional-5/#descdef-container-width

This describes a container feature to be used in the atrule prelude:

@container (width: 20px) {}

It does not describe a descriptor.

[tidoust]

In practice, CSS specs do call that a descriptor too: width is defined with a data-dfn-type="descriptor" attribute in css-conditional-5, and the features are listed in an appendix named @container Descriptors.

The problem is that the term "descriptor" is overloaded in CSS. I do not see how the spec crawler could easily and automatically distinguish between something that can be used within the prelude and something that can be used within the final {}-block of an at-rule. It may be possible to make the crawler smart enough to parse the definition of the at-rule and understand where everything fits. Ideally, if the distinction is important, that distinction would also be explicit in the specs.

See also #479 which, I believe, raised the same problem for the @media at-rule.

[romainmenke]

Ah, I see.
Yes, seems like the same issue as #479

---

@tabatkins Is this something that can be improved in the CSS specifications?
So that spec crawlers can distinguish between what is part of the prelude and what can be used in blocks?

[tabatkins]

Yeah, that's just us misusing the syntax a bit. We don't (currently?) have any overlap between "at-rules that take descriptors" and "at-rules that take declaration-like syntax in their prelude", so doing it this way was convenient.

@romainmenke What's the context for needing the distinction?

[romainmenke]

We'd like to use this data in various dev tools (linters, syntax highlighting, auto complete, ...). Currently most tools use mdn/data or various other manually maintained data sets. We'd like to automate part of this process. Given how underfunded dev tools for CSS are, we are trying to minimize the amount of hours we need to volunteer :)

To be able to use this data we need to know if the descriptors listed are relevant in the block part, or in the prelude.

We can use hard coded lists of at rules that fall in either group.
This feels brittle but would work fine as long as there isn't any overlap.
New at-rules aren't added that frequently.

We already have plenty of escape hatches for editorial overrides because not everything can be expressed in the syntax definitions. But we try to minimize this as much as possible.

[tabatkins]

Yes, a hard-coded list would be the way to go, imo. While nothing a priori prevents there from being overlap, I doubt there will be; all the ones with stuff in the prelude are conditional rules that contain style rules in their body; everything else (that has descriptors instead) has a trivial prelude or none at all.

[dontcallmedom]

@romainmenke if indeed you develop a hardcoded list, it would be interesting to see if we could have it incorporated and maintained in webref so that other consumers may benefit from it.

[romainmenke]

Was thinking the same ☺️.
I'll post a list here first.

I don't know the webref internals, so I am unsure how this could be integrated here.