Normalize references to CSS data types in feature object

[germain-gg]

I was going through a lot of compatibility table for CSS properties today. And I realised that there are no standard way of referencing a CSS data type from the feature object

Looking at the CSS Types page on MDN it seems that the convention is to have the name of the type between angle brackets. We lack that consistency in the compatibility data and that leads to inconsistencies

The following files both reference differently

• css/properties/word-spacing percentage is pluralised
• css/properties/font-stretch percentage is singular
• css/properties/opacity percentage is pluralised but has a different description

Normalizing this would help us having a consistent keys in the feature object, a consistent name, description and mdn_url
That information usually exists within the MDN page, so why not on the compatibility table too?

It seems that the JSON schema prevents us from using angle brackets < and > in the key, that could potentially be quite a big change to make

Wanted to gather everyone's ideas around this matter. Keen to hear your thoughts and start drafting what the next steps would be

[ddbeck]

I agree we could use a data guideline for this sort of thing. We'd want to settle on a key name and a description format. If we took an approach like DOM events, we could have some rules like:

• keys in the form typename_type (e.g., percentage_type)
• descriptions in the form <code>&gt;typename&lt;</code> value support

For the actual type name, I think we should let the specifications take the lead: typename ought to be the exact word used in the specification which corresponds to the feature or type involved. (I think the specs mostly use singular, though.)

[jpmedley]

I have a question because I'm not a CSS expert. Does what's listed in the specs match what has to be entered in a stylesheet? It seems like that's what we would want to use.

[ddbeck]

Sometimes that works and I support doing it where it does. We have some features like em (as a key, with description: <code>em</code> unit) for something that ends up in a stylesheet as 1em.

Percentages could work the same, but it's a little weird. Personally, I don't like the idea of a % key.

But things break down with something like text-overflow, which accepts an arbitrary string in quotes (string key and <string> description right now). I think this is the set of types that this issue could help most with.

And there are a few compound types, like <percentage-length> (meaning, you can use a length or a percentage), which covers many units. Those could probably stand to be decomposed (or to have subfeatures for the individual units).

[germain-gg]

Sounds great! Thank you both for your input
I'm happy to start drafting more precise guidelines for that. the docs/data-guidelines.md seems the more appropriate place to start
Let me know if you can think of a better place to host this information

[ddbeck]

I'm happy to start drafting more precise guidelines for that. the docs/data-guidelines.md seems the more appropriate place to start
Let me know if you can think of a better place to host this information

That sounds right to me. Thank you!

[jpmedley]

Sometimes that works and I support doing it where it does. We have some features like em (as a key, with description: em unit) for something that ends up in a stylesheet as 1em.

The point I was going for was that even though you put a number in front of it, you still write 'em' literally in the stylesheet. The situation I had in mind was one that would be analogous to a problem we have in JavaScript where something like Interface.prototype.member is used on the MDN page, but Interface.member is used in an actual script.

[gsnedders]

#18198 seems potentially relevant to this; it's an example where currently multiple things are defined as <ratio> but implementations aren't that simple.