RE: [css3-3d-transforms] preverve-3d and 'Z position' clarifications

> From: Simon Fraser [mailto:smfr@me.com]


> 
> On Sep 8, 2010, at 3:57 PM, Sylvain Galineau wrote:
> 
> > I am trying to understand preserve-3d's semantics and learning 3D in
> general at the same time so
> > forgive any naïve questions.
> >
> > In the current WD, much of preserve-3d and the relationship of the Z
> axis with the CSS stacking
> > context model seems to be defined in the non-normative introduction
> [1]. In particular:
> >
> > # The position on the Z axis of a transformed element does not affect
> the order within a stacking
> > # context. With elements at the same z-index, objects are drawn in
> order of increasing z position.
> >
> > ..is not something that belongs to a non-normative section.
> 
> Yes, the spec needs more normative sections on the 3D rendering model,
> including the interactions
> between z-index and Z position. That's on my to do list.

I can't wait....

> 
> > I assume the Z position of non-transformed elements is implied to be
> 0 but I couldn't find any
> > explicit mention of that.
> 
> That is true. Non-transformed elements lie on the plane of their
> containing block.
> 
> > It is, however, not explicitly defined how the Z position of an
> element is calculated. Is it the
> > Z coordinate of the element's top-left ?
> 
> The Z position of an element is computed from the center of the border
> box.

That definitely should be specified too ! 

> 
> > Now, if we preserve the drawing order then will an element with a
> lower z-index and a higher Z
> > position find itself covered by a higher z-index element with a lower
> Z position ? An element
> > with a lower z-index could also intersect one with a higher z-index,
> right ?
> 
> When transform-style is 'flatten', you can consider 3d transforms to be
> just a painting effect (like 2d transforms),
> and to not affect the rendering order. (Note that WebKit does not
> currently behave this way; it depth-sorts sibling elements with 3D
> transforms in this case).
> 
> When transform-style is 'preserve-3d', a stacking context is created,
> and descendant elements in that stacking context are depth-sorted first
> according to z-index, and then by Z position (so elements at the same
> Z-position will be layered according to their document order/z-index).
> Untransformed elements are considered by be in the z=0 plane.
> 
> Note that 'preserve-3d' sets up a 3D space which is shared not only by
> children, but also by all descendants reachable by a chain of
> containing blocks all of which have 'preserve-3d'. In other words, in
> the following:
> 
> <div id="root" style="transform-style: preserve-3d">
>   <div id="intermediate" style=""transform-style: preserve-3d"">
>     <div id="foo"></div>
>   </div>
>   <div id="bar"></div>
> </div>
> 
> "foo" and "bar" will be depth-sorted together according to their
> transforms relative to "root".
> 

But if intermediate also creates a stacking context, doesn't this
combined depth sorting conflict with normal stacking context rules ?
Or is the stacking context created by the topmost preserve-3d containing
block ?

> The spec is deliberately vague about what happens when 3D-transformed
> elements intersect, because proper intersection will be hard to
> implement for many UAs. We expect this to remain unspecified.

Yeah, I'd expect that to be harder on an iPhone but is it a reason to
not cover it at all and have odd and creative incompatibilities vs. making 
it optional and specified ? To be honest I haven't thought through good
use-cases but I'm not necessarily comfortable with the least capable
UA platforms constraining the feature scope and resulting in interop
issues we might have to resolve at some point anyway.

Received on Friday, 10 September 2010 02:10:42 UTC