[css-view-transitions-2] [css-pseudo-4] Clarify ordering of `::view-transition` with other tree-abiding pseudo-elements

[khushalsagar]

CSS Pseudo spec defines tree-abiding pseudo-elements which are pseudo-elements that fit in the box tree like DOM elements. All of the view-transition pseudo-elements are also tree-abiding pseudo-elements. While the View Transition spec has a well defined structure (and DOM order) of the internal pseudo-elements, we need to explicitly define the DOM order of ::view-transition with respect to other pseudo-elements.

Proposed Resolution: ::view-transition is the last child of its originating element, i.e., following ::after.

I don't think the above matters during layout/paint. ::view-transition has its own special containing block and a stacking context (which paints last). Style could've been affected by it if selectors like nth-child applied but they don't apply to pseudo-elements. So my rationale for the above resolution is that it being last conceptually fits the fact that its painted last.

Side-note: The DOM order for existing tree-abiding pseudo-elements should probably be spec'd in css-pseudo. I only found it in the animation spec here. But we should ideally define it in the pseudo spec which is referenced by the animation spec.

@flackr @bokand FYI. @fantasai @astearns because this touches the pseudo spec.

[bokand]

Thanks @khushalsagar - one more thing to consider: would it make sense to specify an ordering for the descendant pseudos of ::view-transition? At least for the [Animation composite order]() case? It currently states:

any other pseudo-elements not mentioned specifically in this list, sorted in ascending order by the Unicode codepoints that make up each selector

We actually have an explicit paint ordering for the view-transition-names so I think it'd make sense to order ::view-transition-group based on that rather than lexographically. Similarly for ::view-transition-new and ::view-transition-old.

[khushalsagar]

We actually have an explicit paint ordering for the view-transition-names so I think it'd make sense to order ::view-transition-group based on that rather than lexographically.

That's how its in the spec today, see the text here. We actually rely on the DOM order of the group pseudos to make sure their paint order in the pseudo-DOM matches their paint order in the author DOM.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] [css-pseudo-4] Clarify ordering of `::view-transition` with other tree-abiding pseudo-elements, and agreed to the following:

• RESOLVED: ::view-transition pseudo is the last child of its originating element, after everything else including other pseudo-elements

The full IRC log of that discussion

<fantasai> khush: spec says ::view-transiiton element originates from the document element
<fantasai> khush: but doesn't say what the ordering of the pseudo-element is wrt other pseudo-elements
<fantasai> khush: proposal is, since conceptually it's lifted into containing block, it's meant to be last thing that paints over entire DOM
<fantasai> khush: so having it be after ::after makes sense to me
<fantasai> fantasai: Agree. Should be after everything, including ::after
<fantasai> emilio: is this observable?
<fantasai> khush: I think maybe hit-testing. If the author removes ? from root element, whether you hit ::after or view-transition?
<fantasai> emilio: that's a painting order problem
<fantasai> emilio: It's worth putting in the spec, but might not be observable right now
<fantasai> khush: which is a good time to do it :)
<fantasai> fantasai: if we all agree, let's just resolve and put it in the spec :)
<emilio> emilio: maybe `document.documentElement.getAnimations({ subtree: true })`, if that returns pseudo-element animations?
<fantasai> RESOLVED: ::view-transition pseudo is the last child of its originating element, after everything else including other pseudo-elements

[flackr]

The CSS animations spec would currently put these pseudos after ::before but before element content and ::after pseudo. You'll need to update https://drafts.csswg.org/css-animations-2/#animation-composite-order to reflect this resolution.