W3C home > Mailing lists > Public > www-style@w3.org > March 2015

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

From: Simon Fraser <smfr@me.com>
Date: Wed, 11 Mar 2015 09:48:57 -0700
Cc: www-style <www-style@w3.org>
Message-id: <2CB24AF3-341B-47F3-BE95-E722375AEA5A@me.com>
To: robert@ocallahan.org

> 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 <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.

Simon
Received on Wednesday, 11 March 2015 16:49:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC