You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-transforms-2] definition of Accumulated 3D Transformation Matrix has incorrect loop exit condition #6191
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 elementis 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!
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.
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.
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.
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?)
Activity
mattwoodrow commentedon Apr 12, 2021
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:flatwas considered to the element that establishes the 3D rendering context.smfr commentedon Jun 23, 2021
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 commentedon Oct 19, 2021
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
perspectiveapplies 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 commentedon Oct 26, 2021
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-3dsiblings can also intersect in WebKit' model, and maybe the way to think about WebKit's model is thatpreserve-3dpulls more things into that set of sibling intersections?)[css-transforms-2] Add tests for accumulated 3D transformation matrix.