Repository navigation
[css-shared-element-transitions-1] should animations retarget to new positions smoothly #7813
Description
In shared element transitions we use CSS animations to change the position and size of the pseudo elements from the "old" values to the "new" values, where new values are taken from the represented element (perhaps once a frame, depending on #7812).
If the represented element changes position abruptly, this will cause the interpolated position of the pseudo element (that's mid-animation) to also change its position abruptly.
Now, since these are UA generated animations, we have an opportunity to "smoothly retarget" to the new position by stacking several animations with a "to" keyframe and an implicit "from" keyframe, which would do a c-inf continuity on the path of the pseudo element.
That's adding a bunch of complexity but provides a nice polish for a page that tends to move the target element around with something like a layout shift: the animations would by default be always smooth
Should we do this?
Activity
khushalsagar commentedon Sep 30, 2022
I think we can defer this until we see use-cases hitting this in practice. The whole point of the updateDOM callback is to allow the developer to fetch all resource required for a stable layout.
If the DOM does change, we can set up a new CSS animation with the original
fromstate to the newtostate. That will cause a jump but that would've happened without the transition anyway. The reason I'm suggesting doing something when the DOM changes is because the element's snapshot has to be in sync every frame (to be live). So if the snapshot size changes we need to make the replaced element rendering it is up to date.@tbondwilkinson (this came up at TPAC).
vmpstr commentedon Oct 19, 2022
removing agenda, since I think the proposal is to not retarget for now, and revisit later