[css-view-transitions-2] how do we decide whether to use layered capture?

[khushalsagar]

If a css property decides capture mode, how do we resolve when it's different between old/new DOM. we generally err towards resolving such conflicts from new DOM state. But in this case it changes how the old snapshot was captured so we likely need to stick with the old DOM value.

Also, for entry animation case, we should decide this once when capturing new DOM. So if the property changes mid-animation it has no impact similar to removing the name mid-animation.

@noamr

[noamr]

We haven't resolved on having an opt-in in the first place yet, perhaps we should repurpose this issue to resolve on whether this is an opt-in, including on its old/new behavior?

[khushalsagar]

SGTM, decide on whether to have an opt-in and if so resolve when it's different between old/new DOM.

[noamr]

From the explainer:

Is layered always better?

In short, no. Layered works best for animations that superimpose the two states on top of each other and animate them as if they were one morphing element. For other animations, like slide animations (see the header in this demo, layered capture doesn't make sense and might look odd. Having the two layers as content often makes more sense in that case.

In addition, when the two states are very different, layered animation might result in discrete animations (e.g. between a circle and a square clip-path), which would feel less smooth than crossfade.

Backwards compatibility & opting in/out

Backwards compatibility analysis using the HTTP archive and trying some sites with the new mode shows that very few pages would be affected by this, as the vast majority relies on the default transition. However, any slide transition would feel a bit broken (like the demo above). That's because the ::view-transition-group pseudo-element now has reach animations that weren't there before, and customizations that rely on changing its keyframes or its descendant keyframes would create a very different effect than before.

There are 3 ways to go about this:

1. Have only layered capture. Authors can achieve flat capture by creating a container and making their current participating element into "content" which would still be flattened.
2. Add a new pseudo-element that animates the effects and box decorations, and leave the ::view-transition-group as is. This would also simplify things for people who want to play only with geometry and not with the effects. This won't solve all backwards compatibility issues, but it would solve most of them and would make a clean separation between animating geometry and animating properties.
3. Expose a property that opts in or out to this new behavior.