[css-values-4] Specify how to determine the type of a standalone `<dimension>`

[cdoublev]

A feature dimension value specified with a math function matches <dimension> in <mf-value>:

<mf-value> = <number> | <dimension> | <ident> | <ratio>

According to CSS V&U, a math function can only resolve to a subset of <dimension>:

A math function resolves to <number>, <length>, <angle>, <time>, <frequency>, <resolution>, <flex>, or <percentage> according to which of those productions its type matches.

So implementations should either expand <dimension> to this restricted set when it is produced by <mf-value>, or they should skip type checking a math function matching <mf-value>, since <mf-value> must be validated against the grammar of the specified feature value anyway.

This can be clarified or, <calc-sum> could be produced instead of <number> | <dimension> | <ratio>, which would be on par with *-progress(<mf-name>, <calc-sum>, <calc-sum>), which requires validating <calc-sum> according to the grammar of the specified <mf-name> (or only its numeric type? #10802).

This would mean that queries like @media (10vw + 1rem < width) {} or @media ((10vw + 1rem) < width) {} would work.

[tabatkins]

So implementations should either expand to this restricted set when it is produced by , or they should skip type checking a math function matching , since must be validated against the grammar of the specified feature value anyway.

I don't understand what you're asking for here. A math function resolves to one of those types. Those types match <number> or <dimension>, which is what <mf-value> requires. So a valid math function (per its normal validity rules) is always a valid <mf-value>.

[cdoublev]

Right, sorry, <dimension> does not expand to these types. Each of these is a <dimension>.

My point is that for an input calc(1px) < width, a CSS parser processing the grammar would first see <number> and fail to get a match, then try to replace it with a math function but fail to match its numeric type, then see <dimension> and fail to get a match and is not allowed to replace it with a math function.

[cdoublev]

I have poorly explained the core problem here, sorry.

10.9. Type Checking (CSS V&U) specifies that math functions "can be used anywhere a value of [<length>, <number>, etc.] is allowed", and how to determine the type of a calculation based on this type, but not where a standalone <dimension> is allowed, like in <mf-value>.

Before *-interpolate(), <mf-value> and <calc-value> was the only places where a standalone <dimension> was allowed. But in both places, they do not require a math function to be immediately type checked...

For <mf-value>, the match result must be validated against the grammar of the declared <mf-name> anyway.

In <calc-value>, the match result can be type checked immediately but I think it is simpler to apply it later on the result from matching the top-level math function. This means that when parsing calc(1px + calc(1deg)) against <length>, you would not realize that the top-level math function is invalid after matching calc(1deg) against <dimension> in <calc-value>, but after matching the top-level math function.

Overriding the value definition of <mf-value> with <calc-sum> was just a workaround to avoid type checking in an implementation where it only applies on math functions replacing <length>, <number>, etc. Allowing <calc-sum> might also be considered useful for authors, but this should be discussed in a separate issue.

Note that since all CSS dimension types produce <dimension>, I think you may also see how an implementation can be tricky.

---

Anyway, I think determining the type of a standalone <dimension> is straightforward and should be specified as based on the token unit in 10.9. Type Checking.

[tabatkins]

The issue here is that our use of <dimension> is mostly just an editorial convenience, to allow us to simply talk about the value without having to enumerate all the possibilities (and keep it in sync as we add more in the future). Really, it should be read as <length> | <time> | ... for all recognized types. So we actually want to type-check eagerly, and just take one that matches.

I think determining the type of a standalone is straightforward and should be specified as based on the token unit in 10.9. Type Checking.

Agreed.