[css-typed-om-1] Handle `<decibel>` and `<semitones>`

[cdoublev]

4.3.2. Numeric Value Typing:

Note: As new unit types are added to CSS, they’ll be added to this list of base types, and to the CSS math functions.

Is there any particular reason for not supporting <decibel> and <semitones>?

<decibel> seems to be used in the value definition of cue-after and cue-before (CSS Speech).

<semitones> seems to be used in the value definition of voice-pitch and voice-range (CSS Speech). Both properties are marked as at-risk:

The following features are at-risk, and may be dropped during the CR period: voice-balance, voice-duration, voice-pitch, voice-range, and voice-stress

Both <decibel> and <semitones> are defined as <dimension>s:

The <decibel> type denotes a dimension with a "dB" (decibel unit) unit identifier.

The syntax of <semitones> allowed values is a dimension with the unit identifier st (semitones).

They are missing in CSS Values but generally speaking, wouldn't it be better to refer to the dimensions defined in CSS Values, and avoid explicitly listing the supported dimensions?

To be honest, I'm also creating this issue to ask a question. I would like to know the reason why type entries must be ordered according to the order of the base types:

The base types are "length", "angle", "time", "frequency", "resolution", "flex", and "percent". The ordering of a type’s entries always matches this base type ordering.

I'm trying to find a test case that would fail if they were defined in a different order.

[tabatkins]

Hm, I suppose we can add those. The Speech module is completely unimplemented on the web (and I dunno how much it's implemented anywhere else?), which is why I forgot about it. ^_^

They are missing in CSS Values but generally speaking, wouldn't it be better to refer to the dimensions defined in CSS Values, and avoid explicitly listing the supported dimensions?

I need to add CSS.foo() methods for every unit anyway, so it's not like it would save me any effort.

I would like to know the reason why type entries must be ordered according to the order of the base types:

Because object keys aren't randomly ordered, and if I don't specify an order it'll be impl-specific, and some code might some day depend on one impl's ordering and break in another (or break when an impl updates some code and changes their own ordering). It's a small chance of a future problem, but it's also very easy to avoid entirely by just making the order deterministic from the start.

This ordering is exposed by the .type() method, which returns an object with the types as keys.

[tabatkins]

Actually I'm going to avoid adding these for now, as they're not relevant to the web and the spec thus isn't actually stable in practice. I did add some additional text saying that the set of unit shorthand methods (like CSS.px()) must match the set of units supported by the browser, but only those that correspond to the existing CSSNumericType values; if they're new types (like dB and st would be, as additive-loudness and multiplicative-loudness) they must not be supported, and the impl should ask for them to be added to Typed OM explicitly.