[css-houdini-drafts] [css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?

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

== [css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents? ==
The [section on `CSSTransformValue`](https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects) defines an `is2D` attribute on all of the `CSSTransformComponent`s that is defined as:

>  The is2D attribute indicates whether the transform is 2D or 3D. When it’s true, the attributes of the transform that are relevant to 3D transforms (such as the CSSTranslate.z attribute) simply have no effect on the transform they represent. 

I worry that making it work this way might lead to inconsistent interpretation of these components.  That is, if some code looks at the values of a `CSSTranslate` to determine what it means without looking at the `is2D`, it would interpret a nonzero 'z', whereas that's not the way implementations interpret it.  It also means that any code developers write to interpret what a `CSSTranslate` means needs to consider the `is2D` to avoid this.

Avoiding this would presumably require that the getter for `CSSTranslate.z` always returns a zero value.  Then there's the question of how to get to that state:  presumably setting `is2D` to `true` would have to change the state, but would the `z` setter throw, or just drop the value on the floor?  (I'd hope, at least, that setting `is2D` back to `false` wouldn't restore an old value.)  But I'm not sure if this is actually better.

But since I think the current design has potential problems, I wanted to at least get an issue on file; maybe somebody has a better answer.

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

Received on Tuesday, 30 January 2018 19:05:44 UTC