[css-transforms-2] definition of Accumulated 3D Transformation Matrix has incorrect loop exit condition

[dbaron]

I've read it a few times, and I think that the definition of Accumulated 3D Transformation Matrix has the exit condition of the loop (step 4) stated incorrectly. I've read it a bunch of times... but I'd really like some other folks (cc @mattwoodrow @smfr) to double-check this, though!

It currently says:

While current element is not the element that establishes the transformed element’s 3D rendering context:

However, I believe the loop should execute when current element is the element that establishes the 3D rendering context, and then the loop should terminate after that iteration. In other words, I think this should instead say:

While current element is an element in the transformed element's 3D rendering context:

I've written a testcase that is interoperable across Chrome, Firefox, and Safari, and that I think matches what I'm proposing.

But, again, I'd really like others to confirm that I'm not misreading/misthinking this somehow!

[mattwoodrow]

I agree, we definitely want to include the transform of the establishing element.

I think there's been some confusion and changes around this in the past, where sometimes an element with transform-style:flat was considered to the element that establishes the 3D rendering context.

[smfr]

I think the intent was that the "Accumulated 3D Transformation Matrix" was the matrix you use when rendering the element into the flattening plane of the "establishing" element. So in that sense it would exclude the transform of the establishing element.

[dbaron]

Sorry for taking so long to cycle back to this...

The way "establishing element" is currently defined, though, I think the flattening plane is really in the parent of the establishing element. The parent's perspective applies to the entire 3D scene, and the establishing element can intersect in 3D with its descendants -- and which one is in front can change as its transform changes. That said, I don't think anything in the spec explicitly says that, either, and I think it probably should.

[dbaron]

Like #6238, I think this is a case where the current definition in the spec makes sense with WebKit's model of what constitutes a 3D Rendering Context (which I think extends one element closer to the root than the spec's model), but doesn't make as much sense with the spec's model. (Or maybe that's not the best way to think about WebKit's model, since non-preserve-3d siblings can also intersect in WebKit' model, and maybe the way to think about WebKit's model is that preserve-3d pulls more things into that set of sibling intersections?)