Some CSS properties/types have issues with values

[queengooborg]

I have been working on a big update to the mdn-bcd-collector project to parse values directly out of enumerated types, so that the collector is able to better track new CSS property values when specifications update.

However, I've noticed that there are a number of properties and types that do not define all of the applicable values:

• display property (css-display spec)
  • Does not have values entries for any of the enumerated types (ex. <display-outside>)
• display property (mathml-core spec)
  • No values entry for the math value
• <layout-box>, <paint-box>, <coord-box> (css-box spec)
  • No values entries for the enumerated types they build on
• <counter-style> (css-counter-styles spec)
  • No values entry for <counter-style-name>
• outline-style property (css-ui spec)
  • No values entry for <outline-line-style>
• font-size-adjust property (css-fonts-5 spec)
  • Has a values entry, ex-height | cap-height | ch-width | ic-width | ic-height, that should be separated

For now, we're working around the problem with a manually curated list, but it'd be helpful if these type values were included upstream!

[tidoust]

I'm afraid that you're going to have a hard time relying on the values entry of properties in CSS extracts. Webref merely tries to capture what specs define. The values entry is not the result of parsing the value of a property to extract a list of enumerated types. It merely lists whatever the underlying spec defines through a "value" definition for the property.

Depending on the spec, this may be:

1. Actual values of an enumerated types. Exactly what you need. But that's not the only possibility and there is no guarantee that the spec will define any/all values.
2. A specific value that the spec wants to higlight, for instance the css-display spec only defines list-item for the display property, which is one of the possibilities of <display-listitem>. It does not define <display-listitem> or any other value though. The enumerated types are merely seen as intermediary grammar constructs.
3. A more complex grammar construct, such as the one you mention for the font-size-adjust property.

Ideally, the specs would be more explicit about values that a property can take. In some cases, the fix is easy because the spec already goes through the values and all that is needed is a bit of extra markup. In many cases though, more editorial work is needed. We haven't tried to push in that direction yet. That would be the right "upstream" ;)

In short, the CSS extracts only appear to contain what you're looking for, but the values entry of a property merely lists the values that the spec defines, not the values that the property may actually take.