Add formal syntaxes for `<system-color>` and `<deprecated-color>`

[tidoust]

Via https://github.com/w3c/webref/issues/1519#issuecomment-3120290261

The CSS color specs define a number of values that the <system-color> and <deprecated-color> types can take but not synthesize things in a formal syntax. Ideally, the syntax of these types would be:

<system-color> = AccentColor | AccentColorText | [...] | <deprecated-color>
<deprecated-color> = ActiveBorder | ActiveCaption | [...]

Approaches to consider to get these syntaxes into Webref by order of preference:

1. Craft a PR against the specs to introduce the formal syntax there.
2. Explore the possibility to extract and use values in Reffy when a more formal syntax does not exist. Make sure that this does not create bad syntaxes for other constructs though (and note a patch would likely still be needed to add <deprecated-color> to <system-color>).
3. Create a patch in Webref, but note the patching mechanism is not well-suited for this type of permanent updates.

[cdoublev]

(1) has been rejected a few times in the past, like for <dimension-unit> (now <attr-unit>) in https://github.com/w3c/csswg-drafts/issues/9648#issuecomment-1832692281. But I think <absolute-size> and <relative-size>, <age>, <gender>, could be updated.

I explored (2) but quickly dismissed it because the logic to identify these keyword lists would certainly be brittle.

Below are the productions that expand to a keyword list but that I have not mentioned above:

• <named-color>
• <outline-line-style>
• <page-size>
• <scroll-button-direction>
• <timeline-range-center-subject>
• <timeline-range-name>

I hope this helps! =)

[tidoust]

Thanks, that helps! It suggests that there's no easy way to avoid maintaining such data manually somehow and somewhere:

• For somewhere, we've refrained from doing this in Webref until now because @dontcallmedom and I are confident that we won't have the time to track and maintain data beyond (hopefully) temporary patches. Now, with the understanding that we would most likely do a poor job at maintaining the data ourselves, if that effort is already done multiple times across projects, and if people are ok to raise data updates here, I can look into seeding the data in Webref.
• For somehow, use of actual patches as currently done in Webref could work but seems ill-suited, and is probably going to make maintenance a nightmare. A simpler mechanism, e.g., using simple JSON files, seems more convenient.

[cdoublev]

I would help reporting any update if you decide to produce this data, but I do not think it is worth it.

That said, if specs do not output a formal syntax because it would not be human-readable, bikeshed should ideally produce a markup for machines to synthesize it, assuming it cannot do it by itself (in a Type Index appendice).

For example, with an alternative-for attribute assigned the CSS type producing it. This would allow to synthetize a CSS type from alternatives defined in different specs, like <color> or <timeline-range-name>.

Relatedly, the "terminal" CSS types produce a CSS token type but are not defined with a formal syntax, like <number> = <number-token>, <ident> = <ident-token>, etc... Like many CSS types that produce a single CSS type, usually with specific context/grammar rules (restrictions), such as <counter-name>, <counter-style-name>, <dashed-ident>, which are all <custom-ident>.

[tidoust]

There now is a better suited (though somewhat constrained to start with) patch mechanism to handle setting syntaxes to CSS constructs when they're missing. I included most list-based constructs mentioned in this issue in the initial list of patches: <system-color>, <deprecated-color>, <named-color>, <outline-line-style>, <page-size>, and <scroll-button-direction>. See #1759 for the new syntaxes (the diff in the pull request may evolve as new crawls get made). We also added a new issue template to suggest CSS syntax patches.

<timeline-range-center-subject> and <timeline-range-name> require spec fixes. I create separate issues to track them.

I added a couple of "terminal" constructs, not sure how exhaustive we want to be there though. To be addressed over time based on actual needs. I'm closing this issue in favor of more specific ones, which you're welcome to create ;)