[css-transforms-2, css2.1] Define the pseudo stacking context concept

[chrishtr]

For de-facto [1] interop [2] reasons relating to WebKit/Blink implementation behavior, a pseudo stacking context should be defined.

Proposal: an element induces a pseudo stacking context if at least one of the following holds for the element:

• Induces a stacking context
• Is positioned
• Has backface-visibility: hidden
• Specifies columns (has non-auto column count or width)
• Scrolls overflow (note: not overflow: hidden with or without overflow)
• Is an embedded object, video, or canvas

[1] This concept is very similar to that for a "self-painting layer" in WebKit and Blink. In Blink at least, there are couple of additional corner cases that cause self-painting layers, such as overlay scrollbars. Also, there are some unreliable corner cases, such as whether an iframe is composited or not. I don't think these should be specified. Instead Blink and WebKit should work towards not requiring self-painting layers for these cases.

[2] Elements which induce a pseudo stacking context will likely be specified to:

• Paint-as-if-positioned in the paint-order algorithm from CSS2.1 See anything that creates a stacking context should sort in the positioned descendants z-ordering list #2717 for related discussion.
• Define a backface-visibility root. See [css-transforms-2] Preserve-3d + backface visibility semantics need to be clarified #918.
• Define 3d-context-flattening-eligible. Also tracked in [css-transforms-2] Preserve-3d + backface visibility semantics need to be clarified #918.
• Define perspective-containing-block-ancestor-eligible. Also tracked in [css-transforms-2] Preserve-3d + backface visibility semantics need to be clarified #918 .

[mattwoodrow]

I don't think we can have the last two conditions in the first list.

Overflow:scroll shouldn't create a pseudo stacking context (unfortunately), since it should be possible for things outside the scroller to interleave things inside. That'd be a significant webcompat change I think.

Videos/canvas don't paint as positioned for gecko, and the actual video is sorted separately to the background for a video element (content group, and backgrounds/block-backgrounds respectively)

[chrishtr]

Overflow:scroll shouldn't create a pseudo stacking context (unfortunately), since it should be possible for things outside the scroller to interleave things inside. That'd be a significant webcompat change I think.

Pseudo stacking contexts aren't stacking contexts. They are just paint-as-if-positioned, plus the relationship to backface-visibility and maybe preserve-3d.

As for web compat: Blink already does it, so it's web compatible. And I do think that it is likely not good that backface-visibility leaks across scrolling elements.

Videos/canvas don't paint as positioned for gecko, and the actual video is sorted separately to the background for a video element (content group, and backgrounds/block-backgrounds respectively)

On reflection, I think it's fine to not specify this case. These elements can't have children anyway, so it's just about paint-as-if-positioned behavior. Right now Blink and WebKit both paint them as if positioned due to limitations in their rendering architectures. Blink is working on fixing that and it will eventually be fixed.

[mattwoodrow]

Overflow:scroll shouldn't create a pseudo stacking context (unfortunately), since it should be possible for things outside the scroller to interleave things inside. That'd be a significant webcompat change I think.

Pseudo stacking contexts aren't stacking contexts. They are just paint-as-if-positioned, plus the relationship to backface-visibility and maybe preserve-3d.

As for web compat: Blink already does it, so it's web compatible. And I do think that it is likely not good that backface-visibility leaks across scrolling elements.

Oh interesting, I wasn't aware that Blink/WebKit were doing that.

Made a quick testcase to display the difference: https://codepen.io/woodrow_matt/pen/jONXjNG

I think overflow:scroll isn't painting as positioned, since the red (actually positioned) is still on top. It's definitely causing the background (blue) and content (image) to form a group and not get the orange floated color between them though.

It feels a bit weird to have overflow:hidden and overflow:scroll result in different paint orders.

Anyway, we should probably do that as a separate change if you want to try spec it, since it's a definite behaviour change for Gecko.

[chrishtr]

It feels a bit weird to have overflow:hidden and overflow:scroll result in different paint orders.

I agree. I think we should avoid spec'ing this unless we are forced to.

[dbaron]

This issue is connected to a resolution shortly before it was filed (see also minutes).