[css-transforms-2] Preserve-3d + backface visibility semantics need to be clarified

[smfr]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23015

[css-meeting-bot]

The CSS Working Group just discussed backface visibility, and agreed to the following:

• RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works

The full IRC log of that discussion

<heycam> Topic: backface visibility
<astearns> github: https://github.com//issues/918
<heycam> mattwoodrow: current spec says that backface-visibility only applies to the element it's on, not descendants
<heycam> ... doesn't say it would create any plane or layer, which Gecko faithfully implements
<heycam> ... other engines create a plane for all descendants but not positioned descendants
<heycam> ... which is not something there's any precedent for, seems a bit crazy. would prefer backface-visibility create a stacking context
<heycam> smfr: I think in WebKit it does create a stacking context, not a containing block
<heycam> mattwoodrow: maybe it is that it doesn't create a containing block
<heycam> chrishtr: definitely doesn't create a stacking context
<heycam> smfr: I'd be scared to change hte behavior of backface-visibility...
<heycam> mattwoodrow: so try to find a descroption of what it actually does. affects itself and non-positioned descendants?
<heycam> chrishtr: self painting layers reset the backface visibility thing
<heycam> mattwoodrow: don't know how to describe it for the spec
<heycam> chrishtr: similar to the set of things dbaron found that caused "painting as if positioned"
<heycam> ... in CSS 2.1, positioned elts paint later than regular elements
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
<heycam> ... anything that has an effect-y thing on it
<heycam> ... this is exactly what is on self painting layers
<heycam> ... so we could define it that way
<heycam> florian: where else did we run into this?
<heycam> chrishtr: might have been another case yes
<heycam> ... but the thing about hte paint order is one that's not specified properly, is that right?
<heycam> mattwoodrow: most of hte psecs that create stacking ocntext say that. but they mean create a stacking ocntext and sort it with positioned descendants
<heycam> chrishtr: overflow:hidden, backface-visibility, SVG elements and other atomically replaced elements, ...
<heycam> ... CSS clip probably
<heycam> ... and the rest of them do create stacking contexts
<heycam> ... we should define this, get interop on the table in dbaron's test, then use it for the backface-visibility definition
<heycam> dbaron: I don't think there's a whole lot in there that's not creating a stacking context
<heycam> ... CSS clip only applies to things that are positioned
<heycam> chrishtr: but in terms of the "painting as if positioned"
<heycam> ... I think overflow:clip is the most common
<heycam> dbaron: have we added that yet?
<heycam> chrishtr: I mean overlfow:hidden and scroll
<heycam> ... on the issue in which this table resides, I mention there's a silly quirk in Chrome and probably WebKit, not triggering self painting in some bizarre corner cases of scrolling
<heycam> smfr: WK does not create self painting layers for [...]
<heycam> dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list
<heycam> mattwoodrow: don't think so
<astearns> s/[...]/overflow:hidden/
<heycam> mattwoodrow: overflow:hidden isn't a stacking context, can interleave things inside and outside, so can't go in the positioned descendants list
<heycam> smfr: so is everything on the list make stacking context?
<heycam> mattwoodrow: yes
<heycam> chrishtr: overflow:hidden does not create a self painting layer (in Blink)
<heycam> ... if there's overlfow:scroll but is in effect like overflow:hidden since there's nothing to scroll, then we skip it
<heycam> ... that's something we could change in Chrome
<heycam> ... in any case, is this a good way to spec it?
<heycam> mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...]
<dbaron> I think Gecko calls this "pseudo-stacking context"
<heycam> RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works
<heycam> dbaron: some of this would be easier if there's a spec to put this old CSS 2.1 text to evolve it
<heycam> ... maybe a central painting spec
<heycam> -- break until 4pm --
<TabAtkins> ScribeNick: TabAtkins

[smfr]

Until we have a new spec, css-transforms-2 should more clearly specify backface-visibility:hidden. Matt, would you like to take a stab at this?

[chrishtr]

There are two aspects to this issue: preserve-3d and backface-visibility.

For backface-visibility, there was a resolution earlier this week that backface-visibility:hidden should also apply to all descendants that are not pseudo stacking contexts (#4360).

[chrishtr]

For preserve-3d: we could use the same concept.

The current Gecko semantics are that the DOM ancestor of an element flattens if it does not have transform-style: preserve-3d.

Proposal which relaxes the above a bit: only elements that induce pseudo stacking contexts can cause flattening.

Thus this example would preserve 3d across the #middle div:

<div style="transform-style: preserve-3d">
  <div id=middle>
    <div style="transform: rotateX(100px)"></div>
  </div>
</div>

But not:

<div style="transform-style: preserve-3d">
  <div id=middle style='position: relative'>
    <div style="transform: rotateX(100px)"></div>
  </div>
</div>

This will probably improve interop, makes it a bit easier to structure content in some cases, and may be more consistent to reason about if we do the same thing for backface-visibility: hidden.

[chrishtr]

Now for perspective CSS:

Blink and WebKit both use the enclosing stacking context ancestor that is composited. Therefore, behavior is a side-effect of compositing. :(

If an element has a 3D transform, then its nearest DOM ancestor with perspective is also composited (and because it has perspective it is also a stacking context). However, there may be an intermediate stacking ancestor that is below the perspective and above the transformed element.

Example 1 (perspective is applied to #inner in Blink and WebKit:

<!doctype HTML>
<div id=p style='perspective: 100px'>
  <div style="position: relative; will-change: transform">
    <div id=target style='transform: translateZ(-200px); background: lightblue; width: 100px; height: 100px'>
  </div>
</div>

Example 2 (no perspective applied in Blink (still does in WebKit, not sure why), only because of compositing.

<!doctype HTML>
<div id=p style='perspective: 100px'>
  <div style="backface-visibility: hidden">
    <div id=target style='transform: translateZ(-200px); background: lightblue; width: 100px; height: 100px'>
  </div>
</div>

[chrishtr]

Blink should be able to change behavior to not depend on compositing any more for perspective, along with a corresponding change to preserve-3d.

[mattwoodrow]

For backface-visibility, there was a resolution earlier this week that backface-visibility:hidden should also apply to all descendants that are not pseudo stacking contexts (#4360).

My understanding of the resolution was that backface-visibility:hidden would establish a pseudo-stacking context, such that the backface of the element and all descendants would be hidden, excluding descendants that are positioned or establish stacking contexts (full only, not pseudo).

[mattwoodrow]

The current Gecko semantics are that the DOM ancestor of an element flattens if it does not have transform-style: preserve-3d.

In my mental model, I consider an element with transform-style:preserve-3d, and a parent without (or with a flattening property) to create a 3d rendering context (rather than extend the parent's one). The flattening happens at the root of the 3d rendering context, so the element with preserve-3d is the one outputting a flat representation.

The subtle difference here is that it's clearer that two siblings with transform-style:preserve-3d and a transform-style:flat parent do not intersect with each other, since they're each create a separate 3d rendering context. If we consider the parent to be the one that flattens, then it's harder to explain why the two preserve-3d children don't intersect.

Proposal which relaxes the above a bit: only elements that induce pseudo stacking contexts can cause flattening.

Given the above, I think the required spec text to explain how to differentiate between transform:style:preserve-3d creating or extending a 3d rendering context is complex.

You have to walk the DOM tree (not containing block chain), looking for the first pseudo-stacking context, and check if that also has transform-style:preserve-3d. But, you also have to check the intermediate elements for a flattening property (like overflow:hidden), which does break the preserve-3d, but isn't a pseudo-stacking context.

For that reason, I'd much prefer to trial using the direct parent to check for preserve-3d, just since it's much simpler to explain and understand.

[mattwoodrow]

For perspective, I think we could say the nearest (pseudo-)stacking context ancestor, since we don't need/want flattening properties in the middle to break it (and we're explicitly relying on that for the parallax scrolling effects).

I had a chat to @smfr on Friday, and we'd both still prefer to say the DOM parent though, since it's
simpler, and consistent with transform-style.

Would you be ok with trialing this behaviour, and we can reconsider the approach if there's serious webcompat breakage?