If I remember correctly, every element gets rasterized instead of just exiting ones. Don’t know why they did it this way.

So many design decisions that run completely counter to everything I tried to establish with Relative Animation. There must be a reason, I’ll find out soon

I’ve read in several places that “View Transitions are like FLIP animations” but that is in no way correct. They start from identity instead of end at identity.

Now I get to figure out why they were implemented this way

It’s possible to set the animation-composition of a View Transition to add or accumulate, which only gives nonsensical results.

This reinforces my assertion there is no useful non-relative pattern for additive animation

That’s actually a well written Signals library for React, Preact, Solid, Svelte 4 stores, and Vue shallow refs. There’s a hooks implementation too but it’s bunk

Should mention my standards for undo and redo include a second data model for preservable state, a role which URLs would take, like in this NPM package www.npmjs.com/package/@kvn...

$ find . -name "node_modules" -print0 | xargs -0 rm -rf

My refutation can be put simply, “Come on, bro”

Not without its limitations. Each element is animated separately at every scroll event, which does incur a significant performance cost. I think anime.js wins with fewer allocations?

It also would be hard (but not impossible) to use this animation with virtualized collections

Would perform better if I implemented an anime.js version.

They were going to implement a readonly version of various Web-Animations classes but in the end they only focused on a Flash replacement, full-featured and mutable

Still best when viewed on mobile. This link is the full-page view without the editor: codepen.io/kvndy/full/b...