[css-view-transitions-2] Optimize no content change animations

[khushalsagar]

There are a couple of patterns where an element's position from the old state needs to be retained and animated but not its content. For example:

1. The user clicks a playing video which then animates to a different spot. Details here.
2. There is a list of items where the list is re-sorted.

The cross-fade animation for these cases is an unnecessary perf hit: both because we captured pixels which weren't needed and then ran an animation using them. In case 1, the developer explicitly adds CSS to not display the old pixels. But the browser still has to do the work to capture and retain them until the transition ends.

A better way to do this would be a native API for the author to explicitly tell the browser that the content doesn't need to be animated. So instead of doing a cross-fade, just show the new content directly. Perhaps a new CSS property or addition to the existing view-transition-name like view-transition-name: target no-content-animation. If the developer says "no-content-animation", everything else works the same except no old image is captured. The old element contents are still removed from its parent snapshot. The pseudo-DOM won't generate a ::view-transition-old and there will be no fade-in animation on ::view-transition-new but rest of the UA CSS is the same.

A few questions right now:

• I don't think there should be a size animation for such cases but I could be missing something.
• If we don't find the matching view-transition-name in the new DOM then that would be a bug. Since the moment the new DOM starts rendering, such elements will disappear. We could skip generating any pseudos for such names or abort the transition.

[argyleink]

here's a demo that would benefit from the optimization https://codepen.io/argyleink/pen/VwBKjwj, there's multiple instances where the browser is capturing more than is needed.

here's an example that's similar, but a little different https://codepen.io/argyleink/pen/PoxgOZz. there's a decent amount of javascript to manage whether or not to give a number a view-transition-name, since I wanted it to "do nothing" if it was the same number between old and new. in this case, i interject and hand manage the VT name to get the effect I wanted, but it also happens to help the browser capture less.

both scenarios, I'd love a property that let me articulate these cases.

[bramus]

Big +1 to not capturing/animating unnecessarily.

Perhaps a new CSS property or addition to the existing view-transition-name like view-transition-name: target no-content-animation

Tacking that onto view-transition-name seems weird. Best to have a different property to indicate what aspects needs to be captured.

Something like this (🚲🛖):

view-transition-capture: all | position-only;

The pseudo-DOM won't generate a ::view-transition-old and there will be no fade-in animation on ::view-transition-new but rest of the UA CSS is the same.

I agree that a ::view-transition-old makes no sense, but adding only a ::view-transition-new can cause conflicts with authors relying ::view-transition-new(x):only-child. Because that selector matches in this case, it will result in a wrong animation. Simply ignoring all properties defined by the author in this situation seems counterintuitive.

What is none of those two pseudos was generated at all? The snapshotted view would still need to be inserted into the pseudo tree (to have something visual on the screen), but since its not matched by any of the existing pseudos authors can not target it.

[khushalsagar]

What is none of those two pseudos was generated at all? The snapshotted view would still need to be inserted into the pseudo tree (to have something visual on the screen), but since its not matched by any of the existing pseudos authors can not target it.

This becomes very hard to define because we need a replaced element to show the snapshot. That said, the ambiguity with :only-child is a fair point. Documenting @flackr's idea about this from today's discussion.

We could generate both the old/new pseudos with the following aspects:

• The image for old comes from the live new snapshot.
• The UA CSS sets old at opacity: 0 and new at opacity: 1 instead of the default cross-fade. This is conceptually what the author would do today if they wanted a direct flip to the new image. So lines up better with author's expectation?

[bcole808]

+1 to optimizing the performance when there is no content change. I tested View Transitions in Chrome with a list of about 800 elements and found the performance to slow down a bit when starting transitions.

Here's a fork of the Isotype style animation, with about 600 elements, to illustrate an extremely large number of elements being transitioned: https://codepen.io/bcole808/pen/VwqGoZm In this example, what I'm observing is that when clicking on one of the filters, there is a very long pause after the the pointer input occurs until the animation actually starts. Once the animation starts running, playback is pretty smooth. But the long pause before the animation starts makes it seem like there is a lot of work being done before it starts.

Just showing the newly rendered element and applying a transition to the positioning (without a crossfade) is a common use case. So having a CSS property where developers can specify if there should be a crossfade from the old element to the new element sounds like a good idea.

I agree that just tacking it onto view-transition-name seems weird (or perhaps there could be multiple CSS properties, and then there could be some shorthand way to specify all the values on one property).