[css-values-5] add definition of <dimension-unit>

[SofyaPovarova]

This fix requires #9646 and #9647 to be done at first. Can we add the definition of \<dimension-unit>? <dimension-unit> = '%' | <length-unit> | <angle-unit> | <time-unit> | <frequency-unit> | <flex-unit>

[Loirooriol]

Ok I was a bit confused given the linkes issues where you want redefine <length> and others. This is not about redefining <dimension>, it's just the <dimension-unit> used for attr(), currently defined in prose, right?

[tabatkins]

Can you elaborate on why you need a more specific definition for <dimension-unit>? The current definition is perfectly well-defined, it's just in prose rather than written directly in grammar.

[SofyaPovarova]

We are exploring the possibility of using Webref JSONs for automated validation in JetBrains IDEs. Webref has JSONs with scraped from specification definitions in the main branch and also JSONs with manually fixed data in the curated branch. Some entities don't have value definitions, there were not only primitive values, but also a list of values like \<named-color> or \<dimension-unit> which I mentioned here. I'm working on finding a way to handle these values and the most effective approach seems to be adding definitions if feasible. Initially, I addressed a couple of issues with examples to the Webref repo and was directed towards improving the specifications themselves, which seems to be the right approach. While I understand that it might pose some challenges, I think it's important to at least raise these cases and investigate potential solutions

[SofyaPovarova]

@Loirooriol yep, you're right, the issue is mainly about <dimension-unit> used for attr(), but we need to define <length-unit> + other units, and at first I thought it could be used for <length>. Thank you for pointing to CSS syntax module in your previous comments(deleted now).

Although now I wonder why the prose definition of <dimension-unit> contains '%' if <dimension-token> from css-syntax-3 can't consume '%'. I think it'll be better to define dimension-unit without '%', should it be fixed? 😄

[tabatkins]

We are exploring the possibility of using Webref JSONs for automated validation in JetBrains IDEs.

Okay. In general, we do not write the specs with the intention of them being machine-consumeable; they're intended to be human-readable, instead. That means that some grammar productions end up with prose definitions even if they could be written purely in Value Definition Syntax, because it's clearer for humans and less of an editing hazard.

For example, if we were to explicitly define <dimension-unit> in the grammar, as px | em| ..., then we would have to remember to adjust it every time we added a new unit to CSS. It's very easy to forget to do so, and have the definitions drift from correctness. With its current prose definition, tho, it's always correct.

This does mean that, when you are trying to use them for machine consumption, you might have to manually adjust some things. We're happy to fix mistakes and generally be more consistent in how we handle things (over the years we've done things in slightly different ways, after all), but there is a limit to how much we want to change things to be friendly to machines vs readers.

Although now I wonder why the prose definition of <dimension-unit> contains '%' if <dimension-token> from css-syntax-3 can't consume '%'. I think it'll be better to define dimension-unit without '%', should it be fixed?

No, it's good as-is. The fact that percentages are technically a different kind of token in the parser is an implementation detail; for authors, percentages and dimensions are identical. And in the particular use-case here, where the behavior is basically just "parse the attribute as a number, then smack the unit onto it", percentages and units are indeed exactly the same for authors.

(We do basically the exact same thing in Typed OM, where CSSUnitValue is used to express all dimensions, percentages, and plain numbers. For the latter two, the .unit property is just "percent" or "number". Again, this is because the distinction between these three separate token types is irrelevant for authors, so we don't reproduce the distinction in JS.)