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

tabatkins has just created a new issue for 
https://github.com/w3c/css-houdini-drafts:

== [css-typed-om] Lengths and Angles (and other unit-group objects) 
should have consistent structure ==
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

Please view or discuss this issue at 
https://github.com/w3c/css-houdini-drafts/issues/356 using your GitHub
 account

Received on Friday, 3 February 2017 23:34:16 UTC