A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/w3c/css-houdini-drafts/issues/610 below:

[css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents? · Issue #610 · w3c/css-houdini-drafts · GitHub

The section on CSSTransformValue defines an is2D attribute on all of the CSSTransformComponents 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.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4