[css-transforms-2] transform-style: flat should not create stacking context, and 3D context grouping

[smfr]

Discussion about how transform-style: flat should work.

[mattwoodrow]

We should also resolve what happens when the author specifies transform-style:preserve-3d, but a grouping property forces it to flat.

Consider a testcase that has a preserve-3d element, and then you later add a grouping property that doesn't force a stacking context and containing block (overflow:hidden, clip, clip-path etc).

I find it a bit weird from an implementation standpoint that the change handling for overflow:hidden (which normally has nothing to do with containing blocks) needs to check if we also have transform-style:preserve-3d, and disable us from being a containing block. It's a weird dependency.

I think authors might also find it weird that adding a grouping property not only changes the visual rendering of preserve-3d, but also has the layout change of removing the containing block.

I'd prefer if the flattening effect of grouping properties applied to the rendering model, but not the layout. We could spec that as defining the stacking context/containing block parts of transform-style:preserve-3d are determined by the computed value of transform-style.

[css-meeting-bot]

The CSS Working Group just discussed 3D Transform Interop.

The full IRC log of that discussion

<fantasai> Topic: 3D Transform Interop
<fantasai> mattwoodrow: The current ED is pretyt unclear and seems to not be backwards-compatible with the WEb. We're seeing lots of bugs in Firefox and it's unclera what we're supposed to implement.
<AmeliaBR> Current spec: https://drafts.csswg.org/css-transforms-2/#grouping-property-values
<fantasai> mattwoodrow: Wanted to clear up what we want to do, get implementations and spec to match
<fantasai> mattwoodrow: esp transform-style: 3d
<fantasai> astearns: I see a list of issues in the agenda
<fantasai> mattwoodrow: 4-5 are those cover transform-style
<fantasai> smfr: I think all those issues could be duped to a single issue. They're pretty vague
<fantasai> mattwoodrow: targeting individual pieces
<fantasai> smfr: I can summarize state of problems
<fantasai> smfr: You mentioned speccing webkit behavior. But Webkit behavior is not very definite.
<fantasai> smfr: WebKit tries to follow spirit of current spec
<fantasai> smfr: The main issue is that transform-style: flat creates stacking context, but the draft also says that 'overflow: not visible' also triggers transform-style: flat
<florian> q+
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1950
<fantasai> smfr: Which implies that non-visible overflow creates a stacking context which would be nice but we cna't do that
<fantasai> dbaron: But at this time 'transform-style: flat' doesn't create a stacking context in any implementation
<fantasai> smfr: There's no implementation that has a consistent model for how this all should work
<florian> q-
<fantasai> smfr: So I tried to introduce an auto value to help solve thi issue
<fantasai> ...
<fantasai> q-
<fantasai> AmeliaBR: Background root triggers list, could maybe be adopted as a list of what triggers auto to turn into flat?
<fantasai> smfr: Transforms spec has a list of "grouping properties"... "graphical grouping propeties" should have a master list in a spec somewhere
<fantasai> smfr: Should agree across the specs
<fantasai> smfr: 3D transforms and backdrop-filter
<smfr> https://drafts.csswg.org/css-transforms-2/#grouping-property-values
<fantasai> dbaron: When I brought this issue up last year agreed we should have a consistent term
<fantasai> dbaron: Just variation on whether also becoames a contianing block that trasp fixedpos
<fantasai> AmeliaBR: Still in the spec that SVG elements have special behavior in that 2D transforms on SVG elements don't cause stacking and some other things even though they do on CSS boxes
<dbaron> We also need... an above CSS-level-2 spec that can define base terms for this stuff!
<fantasai> AmeliaBR: That's important in SVG because transforms are the main way to do "layout" in SVG, but does complicate the definition
<fantasai> smfr: I thought every element in SVG was a stacking context, did that change when z-index was added?
<mattwoodrow> q+
<fantasai> AmeliaBR: Yes. Hard to get ppl to implement z-index for that reason
<fantasai> AmeliaBR: Do have a definition for it somewhere.
<fantasai> smfr: stacking context introduces a lot of complexity everywhere. Having also in SVG scares me.
<fantasai> mattwoodrow: spearate issue to raise about the draft
<fantasai> mattwoodrow: Current spec for transform-style says to look for containing block
<chris> q+ to mention this is why we resisted adding z-index to SVG for so long
<fantasai> mattwoodrow: Decided to flatten and switch transform-style to flat
<fantasai> mattwoodrow: But can have a stackign context that's not a containing block
<fantasai> mattwoodrow: I think if we changed ? to use the ?
<fantasai> mattwoodrow: Then we could be clear about when we're supposed to flatten
<mattwoodrow> https://drafts.csswg.org/css-transforms-2/#accumulated-3d-transformation-matrix-computation
<mattwoodrow> q-
<xfq> ack chris
<Zakim> chris, you wanted to mention this is why we resisted adding z-index to SVG for so long
<fantasai> chris: We've slightly moved past that, but this is why SVG resisted adding z-index for many years
<fantasai> chris: The model with painting in SVG was simpler, didn't add stacking contexts.
<fantasai> chris: Adding z-index brings two models into SVG. Worth doing, but a lot of work.
<fantasai> ...
<fantasai> astearns: Need to resolve that we don't create a stacking context but decide what we do instead?
<fantasai> smfr: So we have a resolution for this issue but not an actual fix
<fantasai> astearns: Anyone have an idea of what we should do?
<astearns> explainer: https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo
<fantasai> mattwoodrow: TienYan Chan from Google who use dto work on this but unfortunately doesn't anymore had a long explainer of these problems with a porposed solution for four different things
<dbaron> https://github.com/w3c/csswg-drafts/issues/1944
<fantasai> chrishtr: This was descussed at a breakout session at tpac 2017, was clear that more work was needed. Some cases we couldn't explain still
<fantasai> chrishtr: afaik this explainer document is the closest we got to figuring out what to do
<fantasai> astearns: Maybe another breakout session this week?
<fantasai> chrishtr: It's 12 pages, so would need to reread it to remember what it says
<fantasai> chrishtr: It does seem there's room on the agenda. is there enough interest?
<fantasai> [scheduling]
<fantasai> astearns: so breakout session tomorrow afternoon. If anything on the agenda then that woudl be problematic, lmk so I can shuffle things around
<fantasai> smfr: Tess can cover dark mode
<fantasai> dbaron: Mozilla is next door, so if can't get a room here can get a room there.
<fantasai> <br type=lunch>

[mattwoodrow]

I wrote up an explanation of how Gecko interprets the spec and how the implementation works, along with a bunch of testcases to show some of the differences: https://docs.google.com/document/d/1yb4a_uhTG3KmcbGPta4B9p67v1HO_qY8ZMk-otGOwTc

It looks like the primary difference is that WebKit considers a flattening element (element with a flattening property, or stacking context with transform-style:flat) to be what establishes a 3d rendering context for its children (but not itself), whereas both Gecko and blink consider an element with transform-style:preserve-3d to be what establishes a 3d rendering context for itself and its children.

I think the blink/Gecko interpretation will be simpler to specify, since the root of the 3d rendering context needs to be a stacking context to create a flattened representation. Flattening properties (like overflow:scroll) aren't necessarily a stacking context, so we'd need to make them one, if (and only if) they happen to have 3d descendants. In Gecko/blink the root always has transform-style:preserve, which is explicitly a stacking context.

Commenting here since the css-meeting bot did, but this is effectively the same underlying issue as #3138, #1944, #1951 and #1952.

[mattwoodrow]

We also discussed how WebKit/blink look to non-parent ancestors to determine if we're participating in a 3d rendering context (spec says look at containing block, current behaviour appears to be stacking context), whereas Gecko looks at the direct parent element.

This causes issues when flattening properties are neither a containing block or a stacking context (overflow:scroll), but still need to influence the decision.

Gecko's approach is simpler and avoids this problem (and appears to be largely webcompat!), but does mean that a no-op \<div> will flatten (using the default transform-style:flat).

[tabatkins]

I'm reviewing this, and I'm still confused. :(

As far as I can tell, there are two independent things you want to know about an element's 3d context-ness:

1. Whether its children "see" each other and interact in 3d space, or just get flattened and then CSS-layered.
2. Whether the element maintains itself and its children as a 3d entity when its doing its own 3d transforms, or just flattens its subtree into a plane and then transforms the plane.

These are indeed fully independent:

• A 1-3d (from its parent) and 2-3d (from itself) object, if overlapped with a similar sibling, will interweave its transformed descendants with those of its sibling
• A 1-3d and 2-flat object, if overlapped with a similar sibling, will just be a flat plane, but still be z-ordered according to its own transform (and possibly intersect its sibling, etc).
• A 1-flat and 2-3d object, if overlapped with a similar sibling, will project its transformed descendants away from itself appropriately, then flatten into its parent's plane and be CSS-layered with its sibling.
• A 1-flat and 2-flat object, if overlapped with a similar sibling, will run its descendants' transforms, flatten them into itself, transform itself, get flattened into its parents plane, then CSS-layer with its sibling.

In other words, 2 is about flattening before the element runs its own transforms (into its own plane), while 1 is about flattening after the element runs its own transforms (into its parent's plane).

---

I still can't tell, from @mattwoodrow's descriptions, what the intended behavior of 'transform-style' and flattening properties is in these terms. The term "flattened" is thrown around without sufficient clarification for me to tell whether something is being 1-flattened or 2-flattened in any given instance.

Any help?

[mattwoodrow]

I've written up some proposed wording for this change in #3750, does that help clarify at all?

We've had quite a few changes and misunderstandings here, so it's worth being extra verbose with whatever we come up with.

Gecko's implementation (along with the TR and blink, I believe) is that transform-style:preserve-3d changes both 1 and 2 to the 3d variant, and transform-style:flat (default, explicitly set, or overridden by a flattening property) has both 1 and 2 as the flattened variant.

WebKit and the ED consider 1 to always be 3d, and transform-style just toggles between 2-3d and 2-flattened.

My proposal is to standardize on the former, where the two variants are always changed in lockstep.

[mattwoodrow]

Note that this all independent of the 'auto' keyword, which was added to describe behaviour where the transform-style property is currently ignored on some elements (ones that don't create a 'layer' in blink/WebKit's implementations, never in Gecko).

[tabatkins]

I've written up some proposed wording for this change in #3750, does that help clarify at all?

Ooh, I'll review. (GH's review UI is pretty actively hostile for content with long lines. I'll look in my local client instead, tomorrow.)

Gecko's implementation (along with the TR and blink, I believe) is that transform-style:preserve-3d changes both 1 and 2 to the 3d variant, and transform-style:flat (default, explicitly set, or overridden by a flattening property) has both 1 and 2 as the flattened variant.

WebKit and the ED consider 1 to always be 3d, and transform-style just toggles between 2-3d and 2-flattened.

Ah, this is a nice summary. Thanks.

[chrishtr]

Gecko's implementation (along with the TR and blink, I believe) is that transform-style:preserve-3d changes both 1 and 2 to the 3d variant, and transform-style:flat (default, explicitly set, or overridden by a flattening property) has both 1 and 2 as the flattened variant.

IIRC from the breakout session on this back in February 2019, this was one of the main issues. Let's try to resolve this one way or another this week at TPAC.

In the discussion in 2017 TPAC, it was stated that the ED/WebKit behavior is preferred, according to the notes here:

https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo/edit#bookmark=id.gur0op2192ar

Arguments in favor of Firefox behavior:

• If the a transformed element is not flattened immediately, then its DOM parent must be a stacking context and containing block for descendants. This avoids all possible cases of flattening occurring without those properties present (example: https://codepen.io/chrishtr/pen/VwZBWvQ).
• All transformed elements in a 3D scene are containing blocks and stacking contexts. This also avoids any weird things happening.
• Easy to implement because of DOM locality
• Treats the root element of a stacking context the same as its constituent elements. For example, in the WebKit behavior, transformed children sort with each other, but not with a flat parent if the parent has a transform.

Arguments in favor of the WebKit behavior:

• Convenient for developers: allows children to sort relative to each other without extra grouping DOM nodes w/preserve-3d on them.
• Others?

[smfr]

Taking to review Matt's changes in #3750.