Re: [css3-3d-transforms] Spec questions

On Oct 17, 2011, at 7:01 pm, Matt Woodrow wrote:

> While implementing the 3d transforms spec for Mozilla I've come up with a few questions/suggestions: 
> 
> - How does preserve-3d affect the definition of transform's containing block/stacking context? 
> 
> When we have a multiple level hierarchy of preserve-3d elements, should depth sorting stay constrained to to each stacking context, or should all elements be moved up into the root-most stacking context before sorting. 
> 
> Using the WebKit 'poster-circle' (http://www.webkit.org/blog-files/3d-transforms/poster-circle.html) as an example, retaining stacking contexts will sort the 12 posters by depth position within a ring, and the 3 rings (as a whole) within the cylinder. This results in 'broken' rendering since the rings can still end up overlapping each other. 
> 
> If the intended behaviour of the spec is to treat all descendants as if they are in the root-most stacking context, then this needs to be clarified. 
The spec probably needs to introduce a term like "depth-sorting context" to explain this. Elements with transform-style: flatten (the default) create depth-sorting contexts, which means that a hierarchy of elements with transform-style: preserve-3d share the same depth-sorting context. All transformed elements in that depth-sorting context are depth-sorted as if they were siblings.

> 
> - "With elements at the same z-index, objects are drawn in order of increasing z position." is very vague. 
> 
> I realize that depth sorting was intentionally left out of the spec to avoid requiring any particular intersection       handling, but feel that this should probably be more clearly explained, as the 'z position' of a plane isn't particularly useful. 
As I mentioned in another post, the spec could refer to Netwell's algorithm: <http://en.wikipedia.org/wiki/Newell's_algorithm>.
> 
> - For transitions, does it make sense to treat translatex() as translate3d() to reduce the number of decompositions required? 
> 
> Quite a few of the other transform functions could also be treated as their 3d component to increase the chances of them matching. Is this actually preferable?
We decided against magic matching rules like this; it would be hard for authors to remember more complex rules than just "the transform functions should match".

Simon