Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-shared-element-transitions-1] should animations retarget to new positions smoothly #7813

Closed
vmpstr opened this issue Sep 30, 2022 · 2 comments
Labels
css-view-transitions-1 View Transitions; Bugs only

Comments

@vmpstr
Copy link
Member

vmpstr commented Sep 30, 2022

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?

@vmpstr vmpstr added the css-view-transitions-1 View Transitions; Bugs only label Sep 30, 2022
@khushalsagar
Copy link
Member

khushalsagar commented 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 from state to the new to state. 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
Copy link
Member Author

vmpstr commented Oct 19, 2022

removing agenda, since I think the proposal is to not retarget for now, and revisit later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-view-transitions-1 View Transitions; Bugs only
Projects
None yet
Development

No branches or pull requests

2 participants