[css-transforms-2] 3-D painting order should treat establishing element's background/border like its content

[dbaron]

§ 4.1.2. 3D Rendering Contexts currently defines the painting order for a 3-D Rendering Context as follows:

The rendering of elements in a 3D rendering context is as follows (numbers refer to items in CSS 2.1, Appendix E, Section E.2 Painting Order):

A. The background, borders and other box decorations of the establishing element are rendered (steps 1 and 2)
B. The content and descendant elements without 3D transforms, ordered according to steps 3—7, are rendered into a plane at z=0 relative to the establishing element.
C. 3D-transformed elements are each rendered into their own plane, transformed by the accumulated 3D transformation matrix.
D. Intersection is performed between the set of planes generated by steps B and C, according to Newell’s algorithm.
E. The resulting set of planes is rendered on top of the backgrounds and box decorations rendered in this step A. Coplanar 3D transformed elements are rendered in painting order.

it then goes on to note:

ISSUE 6: requiring intersection with non-transformed content and descendants requires UAs to allocate additional textures (possibly doubling memory use). Would be more efficient to simply render content and untransformed descendants along with background and borders.

I wrote a simple test for this which I would expect from the spec to match this reference. However, the behavior I get in Chrome, Firefox, and Safari, assuming I'm interpreting this correctly, is as though A and B were done together into a plane at z=0 (i.e., step A is eliminated by merging it into step B). It's not clear to me if that issue was suggesting merging in the opposite direction. However, given that this behavior appears to be interoperable, I think we're probably better off switching the spec to match all of the implementations unless there's a very good reason to want the implementations to all change (given that I suspect it would break some existing web content).

cc @smfr @mattwoodrow

[mattwoodrow]

Agreed, I'm not aware of any complaints with the current behaviour (apart from that inline comment about memory usage), so it seems like a good idea to fix the spec to match.

[smfr]

In WebKit, transform-style: preserve-3d does not establish a 3D rendering context, it just extend it, so in WebKit the body is establishing in your testcase.

It's worth looking at some more test cases to make sure your transformed elements don't also intersect with things behind the establishing element.

The behavior was specified like this because it's akin to how negative z-index works, but I'm OK with saying that backgrounds/borders/box-shadow are all rendered in the same plane an intersected with atomically.

[dbaron]

Related to #926.

[dbaron]

Given that @smfr said he's OK with it, and given:

1. the note in the spec about improved performance/memory use,
2. that it's what Gecko and Chromium currently do, and
3. that, given that the 3D context behavior in the spec also matches the Gecko/Chromium behavior and not the WebKit behavior, it seems like it's likely the more Web-compatible behavior.

I'm going to change the editor's draft to specify it this way.

In particular, to expand on (3) a little bit: Given that, in the presence of preserve-3d (or even without it!) WebKit will perform 3D intersection one element in the tree higher (closer to the root) than the spec says to (and what Chromium and Gecko do), it seems that specifying the WebKit behavior along with the spec's current 3D intersection model has a chance of breaking content, since it would move backgrounds (such as those in test 004.tentative in web-platform-tests/wpt#31375) from being 3D intersected with in all engines to being behind the 3D scene. And given point (1) it seems like there's an advantage to doing things this way, so I think it's probably best to do so.