[css-typed-om] Lengths and Angles (and other unit-group objects) should have consistent structure

[tabatkins]

Right now CSSSimpleLength and CSSAngleValue are dramatically different internally - {value, unit} vs {deg, rad, grad, turn}.

The reason for this is that all the existing angle values are trivially interconvertible, so you can set a value in deg and read it in rad and get a reasonable result. However, only some of the length values are interconvertible - you should be able to set a value in px and read it in in, but not in em.

However, this makes the interfaces annoying to work with - lengths and angles seem similar, but you need fairly different code to interact with them - x.value (assuming it's already in the unit you want) vs x.deg (regardless of what unit it was originally in).

A further complication is the CSSCalcLength interface: it superficially resembles the CSSAngleValue shape, but it's actually completely different. All of the members are independent, rather than separate views of a shared core value - setting a value to x.px and then reading x.in will probably just return null, even tho the two values are interconvertible.

An ergonomics point is that people usually work in a single unit at a time while working with lengths (typically, px or em), so converting between units isn't a huge deal, but when dealing with angles people convert between degrees and radians commonly (because degrees are easier to read/write, but radians are needed for trig).

I'm not sure what the right answer is for this yet, but the ergonomics are currently bad, and need to be fixed.

/cc @dbaron

[tabatkins]

I'm thinking we should have all the "simple" (single-unit) types should be {value, unit}, and we should add a .to(unit) function that converts between units when possible (and throws otherwise).

So CSS.px(5).to("in") works, as does CSS.deg(5).to("rad"), but CSS.px(5).to("em") and CSS.px(5).to("deg") both throw.

This gives us a consistent API between all the single-unit values, makes switching units fairly easy, and makes the API for single-unit and calc look substantially different.

[tabatkins]

Okay, I ended up writing up my proposal more formally: https://tabatkins.github.io/specs/unit-problems/

[shans]

This is a compelling enough and small enough change that we should add it to the specification now, and raise an issue for discussion with the TF in April.

[tabatkins]

Done.