[csswg-drafts] [css-transforms-2] 3-D painting order should treat establishing element's background/border like its content (#6238)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transforms-2] 3-D painting order should treat establishing element's background/border like its content ==
[§ 4.1.2. 3D Rendering Contexts](https://drafts.csswg.org/css-transforms-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](https://dbaron.org/css/test/2021/3d-paint-order) for this which I would expect from the spec to match [this reference](https://dbaron.org/css/test/2021/3d-paint-order-ref).  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 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6238 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 22 April 2021 20:02:59 UTC