Re: [csswg-drafts] [css-view-transitions-1] Clarify implications of scrolling during a transition (#10197)

I think I’ve found a simpler solution that still retargets the end position of the `::view-transition-group(*)` pseudos but in such a way that it’s not affected by the animation duration and so that it also leaves the `::view-transition` untouched (as per @vmpstr’s remark): a `translate` that tracks the scroll delta, applied onto the `::view-transition-group`s.

Three demos:

1. The problem: https://codepen.io/bramus/pen/QwEeOVo/15db2ed6632747c69b0a75b8471e30c6
2. The fix, by manipulating the `::view-transition` overlay: https://codepen.io/bramus/pen/yyJmPQm/7c91e973ecfa235d4861bc64a8d5a713
3. The revisited fix, by manipulating the `::view-transition-group(*)` pseudos: https://codepen.io/bramus/pen/PwzMEPx/c7cc82968abb00a100057c903fcd3f1b

I believe this would also play nice with elements that are inside a scroller, as the `::view-transition` overlay remains untouched. For that to work, it would need to track the `scrollParent` of the source element instead of blindly tracking the `documentElement`’s scrollOffsets.

Question that goes along with this alt fix, is whether that is web compatible or not, as it can clash with sites that are using `translate` in their own keyframes. An alternative here is to set the `translate` on the `::view-transition-image-pair(*)` _(but that might seem a bit weird)_ or to add an extra pseudo whose sole responsibility is to have it respond to scroll.

-- 
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10197#issuecomment-3937172952 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 20 February 2026 21:09:53 UTC