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 :)

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 … 😉

🎉 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