Re: [csswg-drafts] [css-view-transitions-1] Can't we just remove `transition root pseudo-element` and `show view transition tree` from the spec? They seem unnecessary. (#12760)

> Looking at this again, one question I have is why not just remove the `::view-transition` pseudo-element altogether when there is no view transition, and recreate it later?

Sorry for the huge delay in answering.

Other pseudos do this with a single line in the element's description that says when it exists. That's what I've attempted to recreate here by saying that `::view-transition`s only render when they have children. I guess them "only generating boxes" would make more sense. (That's what the spec says for `::before` and `::after`)

> The other thing is that I am a bit hesitant to change spec wording to account for things that are only observable as an implementation detail. It creates additional churn for spec editors and convolutes what the spec represents.

On the one hand, I'm tempted to agree.
On the other hand, the way the spec is currently written seems needlessly convoluted when compared to how other pseudos are specified. Elements like `::before` and `::after` are never created or removed by their spec, they just "generate boxes when their computed 'content' value is not 'none'." (i.e. "this pseudo exists when it does",)
Yet view-transitions goes out of its way to manually create new `::view-transition` elements, declare them to be the `transition root pseudo-element` of a `view transition` and then define a `show view transition tree` boolean that toggles whether or not the `::view-transition` on a specific `view transition` is being shown as the actual `::view-transition` on the one element that they all originate from.

Maybe I don't have the right mental modal, but this feels like a lot of song and dance when it's fine to just say some form of "this pseudo exists when it does".
And I spent quite a while reading the spec to assure myself that yes, all this, in practice, is just saying that.
So then I opened this issue to make sure. Because I was thinking "You can't be creating 3 new concepts, and describing a data model with a bunch of `::view-transition`s that get manually created all co-exist on the same element, and have bespoke state tracking for how to selectively render a specific one of those to tell me that, conceptually, there is just one `::view-transition` that shows up when you can see it."

My change also prevents the current problem where a spec change (element-scoped transitions) has managed to bring the state of the 'show view transition tree' boolean out of line with the state of the actual pseudo(s?) that it was meant to describe.

PS: I've also ported [my PR for this](https://github.com/w3c/csswg-drafts/pull/12767) to view-transitions-2 now.

-- 
GitHub Notification of comment by Psychpsyo
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12760#issuecomment-3730507198 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 9 January 2026 20:41:58 UTC