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

[tidoust]

Via #1519 (comment)

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 w3c/csswg-drafts#9648 (comment). 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>.