[css-view-transitions-1] Can't we just remove `transition root pseudo-element` and `show view transition tree` from the spec? They seem unnecessary.

[Psychpsyo]

View Transitions 1 says that a view transition has a

transition root pseudo-element
a ::view-transition. Initially a new ::view-transition.

This implies that a new ::view-transition gets created for every view transition and they all originate from the document element, all the time.
So then document gets extended with

show view transition tree
A boolean. Initially false.
When this is true, this’s active view transition’s transition root pseudo-element renders as a child of this’s document element, with this’s document element is its originating element.

so that it can control which of these gets rendered and when. (Note: it's only ever one and its contents stop being useful once it stops being rendered)

Would it not be simpler to just fill ::view-transition with content in Setup transition pseudo-elements (like right now), and then remove all that content in Clear view transition? (instead of setting show view transition tree to false)
Rendering an empty ::view-transition does nothing, any references to the transition root pseudo-element can just talk about the ::view-transition on the document element instead and, from what I can tell, no other spec ever tries to read from show view transition tree so it's now unnecessary.

TLDR: ::view-transition is already defined, which implies it to exist anyways and there is currently only ever one of them being rendered so I don't see why show view transition tree and transition root pseudo-element need to exist. They seem to be doing a bunch of paperwork and allocations and defining of stuff for no reason.

I ask because I am implementing this in Ladybird and just not implementing these concepts seems like the most straight-forward way to do that. (and I feel like I must be missing something)

[Psychpsyo]

I've opened #12767 to better illustrate the actual changes I am talking about here.

[Psychpsyo]

@noamr Since I think you might be in a position to comment on this:
Would there be any interest in this?

[noamr]

The :::view-transition pseudo might not have content, but it can have an author defined style, eg background color.

So removing all the content might not be sufficient.

Perhaps removing that element and reinserting it on set up is better. I don't remember what view transitions 2 does as this applies to scoped view transitions in a different way.

[Psychpsyo]

The :::view-transition pseudo might not have content, but it can have an author defined style, eg background color.

So removing all the content might not be sufficient.

In my proposed spec change, this is handled by specifying "This element is only rendered when it has children." for ::view-transition.

I don't remember what view transitions 2 does as this applies to scoped view transitions in a different way.

From what I can tell, looking at the latest draft, the relevant sections have not yet been updated to support scoped view transitions. Document's show view transition tree is still there and being used on every transition, even scoped ones.

[noamr]

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?

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.

[Psychpsyo]

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-transitions 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-transitions 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 to view-transitions-2 now.