[css-view-transitions-1] Clarify implications of scrolling during a transition

[mattwoodrow]

My understanding is that the computed value for 'transform' that is set for the ::view-transition-group selector includes the current scroll position of the Document (as required to place it in the current visual position if the view-transition is started when scrolled down).

This means that the -ua-view-transition-group-anim-transitionName 'from' keyframe includes the initial scroll position, and the (implicit) 'to' keyframe includes the current scroll position (and changes each frame if scrolling happens).

This has the visual effect that scrolling lags behind the movement of the scrollbar (and feels heavy), since the pseudo elements animate to the new scroll position. Obviously this is more pronounced when using a longer transition duration.

Assuming that this is the intended behaviour, it might be worth adding a non-normative explainer so that it's more obvious that this will happen.

[vmpstr]

The behavior of targetting the new location of the element is, of course, intentional, since we want to retarget to the new position anytime that changes due to scroll or any other change.

The behavior of the old position being fixed is a consequence of the fact that we need to support cases where the "old" element is gone. It might have been affected by the scroll, or might have been in a different scroller, or be fixedpos. I would claim that this is intentional.

@noamr I'm not sure what the right spot to add a non-normative note is, but possibly around the capture steps?

[khushalsagar]

+1 that this is working as intended. We retarget the end state of the group's animation to the new element's current state including all sources which contribute to the element's position.

But our implicit assumption was that interactions like scrolling won't happen during the transition since its a transient state for animations and the pseudo-elements consume all the events (via the default UA CSS). If that doesn't work for a use-case, I'd be happy to hear the details and see if we can do anything better.

[jimmy-guo]

The behavior of the old position being fixed is a consequence of the fact that we need to support cases where the "old" element is gone. It might have been affected by the scroll, or might have been in a different scroller, or be fixedpos. I would claim that this is intentional.

But our implicit assumption was that interactions like scrolling won't happen during the transition since its a transient state for animations and the pseudo-elements consume all the events (via the default UA CSS). If that doesn't work for a use-case, I'd be happy to hear the details and see if we can do anything better.

Hi @khushalsagar @vmpstr, exploring options here: Would it be possible to support a configuration to set the desired behavior? (e.g. affected by document scroll, affected by specific scroller, fixed position)

My use case is that I have a list on Page A. Clicking on one of those list items transitions to Page B and does an expansion animation where one image expands into several. (There is 1 shared element transition between Page A and B; the remaining image elements are net new). When I click "back" to navigate back to page B, the reverse of the animation happens where the previously net new images collapse behind the original image. However, because the list on Page A is long, I would like to restore scroll to that list item. Unfortunately, while that works for the shared element transition, the remaining images continue to use their stale positioning and fly off the bottom of the page. It would be great if I could configure those net-new images to make the same adjustments as the shared element.

Alternatives explored:

• Without some way to configure this, I would need to render the images invisibly on both Page A to have the elements follow their "new" positions when transitioning from Page B back to Page A. This is doable, but we lose the ability to rely on::view-transition-old(<name>):only-child for example.

• Unless there is some way to extend -ua-view-transition-group-anim-sharedElementTransitionName which accounts for the new positioning I am missing, I could not have the "net new" images follow the shared element's animation (e.g. animation: -ua-view-transition-group-anim-<sharedElementViewTransitionName>), because each "net new" image has a different width, height, and initial position, as well as unique transforms to run at the same time (e.g. translate left 20px and down 20px) in addition to the positional animation.