Re: [css-transforms] rendering 3D-transformed sibling elements without preserve-3d

> On Mar 11, 2015, at 5:21 pm, Robert O'Callahan <robert@ocallahan.org> wrote:
> 
> On Thu, Mar 12, 2015 at 5:48 AM, Simon Fraser <smfr@me.com> wrote:
> 
>> On Mar 10, 2015, at 9:27 pm, Robert O'Callahan <robert@ocallahan.org> wrote:
>> 
>> Consider example 7 here:
>> http://dev.w3.org/csswg/css-transforms/#3d-rendering-contexts
>> 
>> AFAICT this doesn't match what Chrome and Firefox do (can't test IE). In those browsers, sibling elements can't intersect each other unless preserve-3d is involved somehow. In those browsers, in the absence of preserve-3d, 3D-transformed children are transformed, projected and composited in regular CSS order. I suspect that changing that will create major Web compat issues.
>> 
>> Or am I misunderstanding something?
> 
> Indeed this is a behavior change from my spec re-write which was done to more rigorously define what preserve-3d means, which altered the meaning from “start doing depth-sorting and intersection” to “make the children live in the same 3d space as the current element”, and those don’t mean the same thing.
> 
> I’m not sure how to resolve these two competing uses of preserve-3d. Both have shipped, but I suspect that most content is authored to the WebKit/Blink behavior, which is the "make the children live in the same 3d space as the current element” behavior, and I can find tutorials that describe this behavior, but not that describe the  “start doing depth-sorting and intersection” behavior.
> 
> I'm worried about pages where there are sibling elements using 3D transforms for perspective effects, but normal CSS painting order is assumed. I believe that's what Webkit, Blink and Gecko all do in the absence of preserve-3d. (Am I wrong?) I admit I don't have any examples of such pages at hand, but does that not worry you?

WebKit will do intersection of sibling 3D elements. Blink and Gecko appear to use CSS painting order:
http://www.smfr.org/misc/css/sibling-intersection-3d.html

> 
> If the spec stays as-is, with non-3D content rendered at z=0, then I think we'll have even more problems with 3D-transformed elements unexpectedly falling partially or wholly behind the background of their container.

I agree this is a problem.

The fundamental issue here is that transform-style: preserve-3d has been used to mean two different things:

1. [the old spec] Render child elements in a common 3D space, essentially switching rendering for this element into “3D mode". The typical usage pattern here was:

<div id=“scene” style=“perspective: 500px; transform-style: preserve-3d;”>
  <div class=“transformed1”></div>
  <div class=“transformed2”></div>
</div>

2. [the new spec] Render child elements into a 3D space shared with their parent element. Here the above scene could be:

<div style=“perspective: 500px”>
  <div class=“transformed1”></div>
  <div class=“transformed2”></div>
</div>

but you’d need transform-style: preserve-3d; as soon as you nest transformed elements.

The problem with the old transform-style definition (1 above) is that it doesn’t clearly define where flattening happens. You need transform-style: preserve-3d to say that descendants intersect, but you can’t say that <div id=“scene”> should also flatten, so things get ambiguous when nesting.

perspective: doesn’t help here; it’s just a way to concat a perspective matrix into the transforms of descendants.

I haven’t found a solution where transform-style: preserve-3d can mean both “please enter 3D rendering mode”, and also “please let my children share the same 3D space as me”.

Perhaps we need a new property?

Simon

Received on Wednesday, 1 April 2015 04:53:38 UTC