[css-view-transitions-2] Starting a transition half way through another transition

[jakearchibald]

Imagine a list of items that randomly reorders and changes background colours, with each list item having its own view-transition-name.

Let's say, a reordering happens, then another happens halfway through the previous transition.

By default, the new transition causes the previous transition to skip to the end, and the new transition starts from that point. That gives you a stable start point for the animation, but it doesn't look great visually.

Alternatively, the developer could queue on the previous transition.finished. This gives a smoother animation, but a delay to the interaction.

Something we don't offer right now is the ability to pick up from where the previous transition was at the point of skipping.

In this simple case we could make it work (via an opt-in) like this:

---

During the "old" capture phase:

1. If the developer has opted to continue from the current transition:
   1. For each group in the current transition:
      1. Capture that group as the old state of a named element for the new transition. That includes capturing its border-box. The capture we take may be mid-crossfade.
      2. If an element with that name exists in the current DOM, then it's omitted from any further captures.
2. Continue the capture as usual.

---

However, things get messy in more complex cases:

If the developer is interrupting a state-A to state-B transition with a transition to state-C, they may now have groups in the transition that wouldn't usually be there in a state-B to state-C transition. For example, if state-A to state-B involves header & footer, and state-B to state-C involves header & sidebar, they now have a combined transition involving header, footer, & sidebar. They'd have to carefully plan for this.

Or a case like this:

• The page has a user-avatar. It does not have a view-transition-name.
• A state-A to state-B transition is performed. The user-avatar exists in both states.
• The transition is interrupted with a transition to state-C. The user-avatar exists in both states, but now it does have a view-transition-name.

In this case I don't see how we "continue" the animation of the user-avatar, as it's likely embedded in some other group. This is particularly an issue for the ::view-transition-old from the first transition, since the avatar is somewhere in there as pixels, and we can't extract it.

The only sensible thing we could do here is create a transition group for the user-avatar using its DOM state-B as the 'old' and DOM state-C as the 'new'. That might result in the user seeing multiple user-avatars, since a copy of it is already baked into another group.

Maybe there's a better way?

[SebastianZ]

For the user experience it might probably ok to try the best in that case and choose state-B as the 'old' and state-C as the 'new'.

Though as the author is expected to provide a view-transition-name for state-A and state-B as well, we might also make it as obvious as possible that they're missing something. I.e. there might not be a view transition at all as long as the view-transition-name is only defined for one state.

Sebastian

[jakearchibald]

For the user experience it might probably ok to try the best in that case and choose state-B as the 'old' and state-C as the 'new'.

How would that be different in practice to what we're currently doing?

[SebastianZ]

For the user experience it might probably ok to try the best in that case and choose state-B as the 'old' and state-C as the 'new'.

How would that be different in practice to what we're currently doing?

I just repeated what you suggested by saying "using its DOM state-B as the 'old' and DOM state-C as the 'new'".

Sebastian

[nonphoto]

This way solves the problem and is also reasonably intuitive:

The only sensible thing we could do here is create a transition group for the user-avatar using its DOM state-B as the 'old' and DOM state-C as the 'new'. That might result in the user seeing multiple user-avatars, since a copy of it is already baked into another group.

State A should remain in the pseudo-element tree until its transition is finished, even if the transition has been interrupted with state C. Perhaps setting animation-play-state to paused, or simply animation to none could complete the A transition early and remove the corresponding pseudo-element.

[nonphoto]

This issue also applies to [css-view-transitions-1], should there be a second label?

[nonphoto]

Also the conversation in WICG/view-transitions#157 is relevant here.

[bramus]

A while back I ran a poll (Twitter, Mastodon) asking authors what is missing from View Transitions. Out of the 33 replies, 6 requested this feature, making it the number 1 request (along with scoped transitions and auto v-t-name generation)

Also leaving a note here that many folks call this "interruptible transitions". That term might give the wrong impression though, as some interpret this as being able to stop (and skip forward) a transition. During an internal conversation @tdresser called this "retargetable transitions", which is a term I quite like for this.