[css-values] Grammar syntax for defining excluded idents for <custom-ident> productions

[weinig]

As part of an ongoing effort to generate the parsing and serialization of CSS values from the grammars in specs, another missing piece of information is the prose defined "excluded values" for <custom-ident> productions.

To give some concrete examples, lets take a look at the grammar for the view-transition-class property:

none | <custom-ident>+

In prose below the grammar is the text "none is an invalid for view-transition-class, even when combined with another ."

If instead, that information was available in a machine readable way, parsing and testing would be directly implementable.

I don't have strong opinions on the specifics of a syntax extension, so as a strawman I propose <custom-ident excluding=foo,bar,baz>

For the example above, this might look like:

none | <custom-ident excluding=none>+

Additional properties this would be beneficial for are:

CSS Conditional Rules Module Level 5: <'container-name'> excludes "none", "and", "or", and "not".
CSS Lists and Counters Module Level 3: <counter-name> excludes "none".
CSS Will Change Module Level 1: <animateable-feature> excludes "will-change", "none", "all", "auto", "scroll-position", and "contents".
CSS Color Adjustment Module Level 1: <'color-scheme'> excludes "normal", "light", "dark", and "only".

[tabatkins]

I'm not against this in theory, but I'm concerned about readability. We'd got limited horizontal space, and they're almost always combined with other things. Nice short names are already greatly desired; a three-word non-terminal name is already super long, and that's the minimum number of words your example would contain.

I feel like it would end up, for readability's sake, often being written as

<something> = [ none | <something-foo> ]+ <number>
<something-foo> = <dashed-ident excluding=none>

And if that's what we're going to do, might as well specialize it a little better to encourage that pattern and make it clearer. Not sure how I want to spell it tho.

[tabatkins]

<something-foo> = IDENTTYPE - [ EXCLUDEDKEYWORDS ]

/* like: */

<something-foo> = <dashed-ident> - [ none | foo | bar ]

- isn't currently valid used bare like that, so this is unambiguous with other patterns, especially if it's precisely limited to this pattern. Or maybe we use a different spelling of = to distinguish this pattern from normal grammar definitions, like

<something-foo> is <dashed-ident> - [ none | foo | bar ]

[kbabbitt]

<something-foo> = <dashed-ident> - [ none | foo | bar ]

I like that this lends itself better to line-wrapping than the excluding= syntax. It might also find some use in other contexts, e.g. outline-style which takes all of the border-style values except hidden.

Less a fan of the is spelling - I have to stare at it longer to realize it's not a literal. Would another layer of grouping work for disambiguation if needed?

<something-foo> = [ <dashed-ident> - [ none | foo | bar ] ]

[AtkinsSJ]

Not saying this is better, but what I ended up using in Ladybird's data files was <custom-ident ![foo, bar, baz]>, because it's brief and similar to the numeric range syntax, which I think is the only other place that parameterizes a value.

The subtraction syntax does wrap better, but it also feels less obvious that the keyword list is part of that custom-ident definition.

Could always spread this across multiple lines for readability. Eg,

<custom-ident
    ![ none | foo | bar | baz | something-long ]
>

[cdoublev]

I'm concerned about readability.

Agreed. The list for <family-name> would be very long.

On one hand, there are not that many contexts with reserved keywords. That said, assuming implementations that would rely on this data rely on w3c/webref, this tool could help:

<dfn excludes="none, foo, bar"><<something-foo>></dfn>

Exported by w3c/webref as:

{
  "name": "<something-foo>",
  "type": "type",
  "excludes": "none, foo, bar",
}

On the other hand, authors should also be considered since they can specify a value definition syntax in @property/initial-value, @function, etc. This syntax is restricted but they might find it usefull to exclude some keywords for <custom-ident>.