[css-view-transitions-1] Clarifications on stacking contexts

[fantasai]

https://drafts.csswg.org/css-view-transitions/#view-transition-stacking-layer

Its parent stacking context is the root stacking context.

“root stacking context” isn't a defined term in Appendix E.
Did you mean “root element’s stacking context” or something else?

If the ::view-transition pseudo-element exists, a new stacking context is created for the document element and the document's top layer. The view-transition layer is a sibling of this stacking context.

It's not clear to me what structure you're creating here, is it

• root stacking context
  • document element stacking context
  • top layer stacking context
  • view transition stacking context

or

• root stacking context
  • document element and top layer stacking context
  • view transition stacking context

?

The view-transition layer paints after the stacking context for the document element and document's top layer. This includes the filters and effects that are applied to the document element.

Is this trying to say

• a) the filters and effects apply to everything together, or
• b) they apply to the document element and top layer, and the view transition layer is above these filters and effects

?

[khushalsagar]

We took the term "root stacking context" from the fullscreen spec. I realize now that its not well defined in that spec either : https://drafts.csswg.org/css-position-4/#document-top-layer:~:text=Its%20parent%20stacking%20context%20is%20the%20root%20stacking%20context.

Not sure if that concept should go into the top layer spec or in Appendix E. Latter makes more sense, its supposed to elaborately define stacking contexts. :)

It's not clear to me what structure you're creating here

The second one:

• root stacking context
  • document element and top layer stacking context
  • view transition stacking context

Generally the stacking context for "document element and top layer stacking context" is the root of the stacking context tree but we create a new one during the transition. Since the root element's image comes from the root stacking context. Amongst other things, its related to the question below.

Is this trying to say

Option b, they apply to document element and top layer but not to view transition layer. We paint the stacking context for "document element and top layer" into a canvas to generate the image for the root element and then feed that image into the view-transition-old/new elements.

It's an existing pattern to lift some effects (background color and effects like filter/opacity) from the root element onto the canvas which paints both the root element + top layer elements. So we have to capture the painting of this stacking context to make sure the image for the "root" is correct. It can be a bit odd that view-transition-name is on the root element while in practice it takes the output of the stacking context which includes the root element + top layer stuff. But its building on the same pattern we do for these effects.

[tabatkins]

The concept belongs in Position 4, yeah. I just haven't yet taken the time to define the bits that View Transitions needs to rely on. (The VT layer, which is above the top layers, etc.)

[fantasai]

Merged in clarifications, leaving this issue open to track handling this comment from @khushalsagar:

One point which I want to make sure is obvious is that the root and top layer elements don't paint during the regular DOM if they're "captured in a view transition", a.k.a, computed value of view-transition-name on the root element is not none.

The spec text here is supposed to cover that: https://drafts.csswg.org/css-view-transitions-1/#setup-transition-pseudo-elements-algorithm:~:text=The%20new%20element,until%20new%20exists. If you have any better ideas to include that here (even in a normative note), would be good!

[khushalsagar]

I think the ambiguity here is related to how we describe painting of captured elements:

1. The spec text here says that any element being captured in a transition will not paint or hit-test. The root element can also have this bit set.
2. The spec text here says that when generating an image for the root, also include top layer elements.

Logically 1 would imply that only the root element is generating an invisible box. Top layer elements are being painted as usually. While all elements captured in an image would be generating invisible boxes.

#9159 should fix this.

[mattwoodrow]

It's an existing pattern to lift some effects (background color and effects like filter/opacity) from the root element onto the canvas which paints both the root element + top layer elements.

Is this pattern specified anywhere, apart from background (which is here)?

I had a quick play, and it seems very inconsistent between different effects (filter, opacity, backdrop-filter, mix-blend-mode, isolation etc) and different engine implementations.

[khushalsagar]

^ @chrishtr probably knows. IIRC he worked on the spec discussion + Blink implementation in this area.

[chrishtr]

^ @chrishtr probably knows. IIRC he worked on the spec discussion + Blink implementation in this area.

Example in a spec:

https://drafts.fxtf.org/compositing-1/#pagebackdrop
https://drafts.fxtf.org/compositing-1/#rootgroup

Filters also have this behavior and I think it's in the spec by way of compositing-1. It was discussed at the CSSWG a few years ago.

Chromium should agree with the spec on these points and there are WPTs.