Feature request: Add @position-try allowed properties list

[lifeiscontent]

Summary

The @position-try at-rule currently shows an empty descriptors array in the webref data. It would be helpful to have the list of properties allowed within @position-try rules.

Current State

{
  "name": "@position-try",
  "descriptors": [],
  ...
}

Use Case

CSS-in-JS libraries and CSS validators need to know which properties are valid inside @position-try rules to provide proper validation and autocomplete.

Proposed Enhancement

Populate the descriptors array with the allowed properties:

{
  "name": "@position-try",
  "descriptors": [
    { "name": "position-anchor", ... },
    { "name": "position-area", ... },
    { "name": "top", ... },
    { "name": "right", ... },
    { "name": "bottom", ... },
    { "name": "left", ... },
    { "name": "inset", ... },
    { "name": "inset-block", ... },
    { "name": "inset-inline", ... },
    { "name": "margin", ... },
    { "name": "width", ... },
    { "name": "height", ... },
    { "name": "align-self", ... },
    { "name": "justify-self", ... },
    ...
  ]
}

Reference

Per the CSS Anchor Positioning spec, @position-try accepts:

• Inset properties (top, right, bottom, left, inset, inset-block, inset-inline, etc.)
• Margin properties
• Sizing properties (width, height, min-, max-, block-size, inline-size, etc.)
• Self-alignment properties (align-self, justify-self, place-self)
• position-anchor, position-area

[tidoust]

Yes, that seems good. A one-time patch should be applied to @position-try, as there's no way to extract the descriptors from the spec directly.

Now, the diff-based patching mechanism seems ill-suited for this. The declarative syntax patching mechanism is only for syntaxes, and that seems out of scope for the code that drops duplicates. We probably should write a tiny bit of logic to look for the definitions of the underlying properties, and fill the list of descriptors with a copy.

[cdoublev]

These properties are not descriptors. (@position-try might accept descriptors in the future though.) So you would duplicate a lot of data that is "global" and already available in webref extracts.

See w3c/csswg-drafts#9453 for discussions about a (future) solution for webref to list which properties are accepted in other contexts than style rules.