Post

Did anyone say Retargetable View Transitions (aka Interruptible View Transitions)? I think I’ve got it working (by throwing some extra JavaScript at it) …

My code also works with multiple elements that are being animated as part of a single View Transition. (The recording of this demo here was deliberately done in Firefox as both Chrome and Safari show some visual glitches when the new VT is about to start 😢)

Around the same time last year I hacked something together that generated a custom SVG path to animate the items along it. It took a lot of late evenings to get it somewhat right, but I never really nailed it. The current approach is much simpler, as I whipped this one up in just two evenings :)

Nothing public to play with yet. I need to clean some of the stuff up first :)

0 reposts5 likes

Here’s an updated version of that first demo, using a technique @kvndy.bsky.social taught me: relative animations. The path the dot follows is much smoother now as it doesn’t get interrupted at its mid-flight location but, instead, the new animation gets added to the existing ones. However …

However … the recording I provided in the prev post is not using View Transitions. It is faked and by duplicating DOM nodes. The recording attached to this post however is the real VT one, and as you can see it is glitchy (in all browsers) – something I still need to dig into. To be continued … 😉

Sorry for the logorrhea. A long-running CATransaction used to block rendering. Had to start using backwards fill when Apple fixed it. Animation start time may have somehow been after the current time. It rendered in a new location without an animation to put it back where it came from, for one frame

I didn’t realize it was possible to handle VT retargeting with Javascript, especially for additive and relative. Long ago I fixed Core Animation flickering with a backwards fill. To this day I superstitiously use backwards with Web-Animations. (Behavior is slightly different, unsure if it helps)

Best news ever! The flickering is the pattern’s Achilles Heel. Animations must be applied at the same time property values change since they’re added together, but getting the timing right is implementation dependent

🎉 Yay, I got the glitches fixed! (*) The solution was to do less. No more copying of animations from one element onto the other, I simply directly apply them on the ::view-transition-group(box). (*) In Firefox. Both Chrome and Safari already were (and still are) glitchy :-/

This also surfaced an interesting compat issue: in Chrome WAAPI animations set on the ::vt-pseudos keep existing (until they finish) but no longer have an effect once you start a new VT In Firefox + Safari the animations keep having an effect, which aligns with the behavior of pseudos like ::before