[css-color-4] fix of dfn-for attribute for named-color values

[SofyaPovarova]

Could we modify the "dfn-for" attribute for the named colors table in the named-colors block from "<color>" to "<named-color>"? The table represents the set of values for <named-color>.

[svgeesus]

Good catch, fixed

[SofyaPovarova]

Thank you!

[tabatkins]

Nope, this is broken. Remember that Bikeshed does not chase down the production hierarchy; right now, you've made it so that anything which wants to say <color>/red will fail. (I mean, there's probably not much, if any, of that in the specs today, but still.)

It should be dfn-for="<color>, <named-color>". (And same for the <deprecated-color> production you did for another issue.)

[SofyaPovarova]

Could you please provide an example to clarify what broke down when the "dfn-for" attribute ceased to contain <color>?

I'm relatively new to working on specifications, but I'm really curious about the specifics, especially when it comes to practical examples like this. Thank you!

[tabatkins]

The for values on a definition are just opaque strings that serve to namespace the definition; Bikeshed does not infer anything about the value used. So if you have <color> = <named-color> | ..., and then define a <dfn value for="<named-color>">red</dfn>, you can link to it with ''<named-color>/red'' but not with ''<color>/red'' - Bikeshed does not know that every <named-color> is a <color> as well.

This sort of inheritance relationship needs to be handled explicitly, with for="<color>, <named-color>" giving it two distinct for values.

[svgeesus]

TIL

[tabatkins]

It's on my low-priority list of things to fix some day, now that Reffy is parsing the CSS grammars and inferring these relationships (and forcing us to fix things when there are mistakes). But I have no timeline for it.

[cdoublev]

Out of curiosity, why is the data extracted by Reffy not generated by Bikeshed? I would say because of lack of time, but crawling specs through the network obviously represents unnecessary overhead.

[svgeesus]

Illuminating discussion on the wider issues, but closing here because the specific spec defect has been corrected with #9632