search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.38k stars 643 forks source link

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

Open mattwoodrow opened 3 months ago

mattwoodrow commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

+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.