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

Bramus

@bram.us

21 Jan

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

Bramus

@bram.us

21 Jan

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

Bramus

@bram.us

21 Jan

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

Bramus

@bram.us

27 Jan

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 …

Bramus

@bram.us

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

27/1/26, 10:32 pm0 reposts5 likes

🍥kvndy

@kvndy.bsky.social

29 Jan

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

🍥kvndy

@kvndy.bsky.social

29 Jan

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)

🍥kvndy

@kvndy.bsky.social

28 Jan

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

Bramus

@bram.us

29 Jan

🎉 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 :-/

Bramus

@bram.us

29 Jan

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

Bramus

@bram.us

29 Jan

The trigger here – I’ve been told – is the originating element that determines whether the animations should clear or not. If that element doesn’t change, the animations are kept around. Not sure if that should be the case for VTs though … would you expect them to get cleared with a new VT?

🍥kvndy

@kvndy.bsky.social

30 Jan

I would rather they stick around, as with my preferred animation technique. Conservation of UI energy: to stop an animation, run an equal and opposite one in the other direction (only half joking)