[css-view-transitions-1] WAAPI-created animations on view transition pseudos don’t get cleared when the view transition gets skipped

[bramus]

In https://codepen.io/bramus/pen/JoKMaEd/5b12099cd1f907ac44d63e13a0aacce1 I am animating the ::view-transition-group(box) pseudo using the Web Animations API instead of using CSS.

The code is as follows:

::view-transition-group(box) {
	animation-name: none;
}

document.addEventListener('click', async (e) => {
	const t = document.startViewTransition(() => {});
	await t.ready;
	
	document.documentElement.animate(
		{
			translate: [
				`0px 0px`,
				`100px 0px`,
			],
		},
		{
			duration: 1000,
			easing: 'ease',
			pseudoElement: '::view-transition-group(box)',
		}
	);
});

What caught me off guard here is that when an ongoing view transition gets interrupted, the animations keep on existing. You can do that in the demo by doing consecutive clicks.

My expectation here would be that whenever a new View Transition gets started, the (WAAPI) animations added to the pseudos of the previous View Transition would be cleared as well, as it is a different View Transition (and the view-transition-name could be set on a totally different element).

I talked to @emilio about this, and this apparently is the general way how pseudos work because the originating element of those pseudos remains the same. Perhaps for View Transitions we need to change this behavior and anchor things on the VT instance instead of the originating element? I.e. this would clear the WAAPI-created animations when a different VT starts.

[bramus]

On thing I noticed is that while all engines report an increase in the number of animations when successively clicking, Chrome does not apply those lingering animatoins to the new set of pseudos, whereas Firefox and Safari do.

So if this issue gets a “close no change”, that would be a bug on Chrome’s end.

[bramus]

Playing around with this, I can come up with cases where I would want either behavior:

1. When I layer new (accumulating) animations onto the existing ones, I want the old ones to have an effect. Specific use-case: try and implement “Retargetable View Transitions” in userland
2. When I capture different elements in the two transitions that happen to have the same view-transition-name value, I don’t want the old animations to still have an effect in that case. Specific use case: in this demo the card that gets added to the list gets a fixed v-t-name.

Admittedly the animations in the second scenario would be animations that are set to composite: 'replace', so keeping the old animations around (and have them apply) wouldn’t have an effect anyway because the last animation replaces all preceding ones.

In either case, authors can always loop over all animations attached to a pseudo, and cancel the manually if they want to.

[bramus]

I think I am more and more convinced that the behavior is as expected, and that Chrome has a bug here.

In case authors don’t want the animations to keep having an effect when starting a new view transition, they can always manually cancel the currently running ones.