[nikisweeting]

I also recommend using negative animation delay values if you want to control the progress via JS.

e.g. animation-delay: -1500ms will begin the animation immediately but jump to 1.5s into the animation. Controlling this value with JS lets you effectively scrub through CSS animations via JS, making every animation compatible with game-engine style compute-update-render tick loops.

https://developer.mozilla.org/en-US/docs/Web/CSS/animation-d...

[9dev]

That should also enable iOS style, scroll-offset bound animations, right?

[afavour]

Scroll linked animations are the best way to do that:

https://web.dev/shows/http-203/Qf5wdXOxW3E

Sadly no Safari support yet.

(attaching an active JS event listener to scroll is considered bad because it means your scroll movement gets tied up in the JS event loop. On a fast device it’ll probably be fine but on a slower one things can start getting choppy pretty easily)

[easyThrowaway]

Unfortunately if you're doing any sort of DOM manipulation linked to scroll events it will cause stalls in the main rendering thread, at least on Chrome, and slow down even on faster machines.

[afavour]

The exception there is hardware accelerated CSS transforms, which will work great.

[rasz]

"hardware accelerated" CSS transforms take ~30% of one CPU thread in Chrome, thats a very specific definition of great :(

[easyThrowaway]

I should check it on a more recent release, but at least on Chrome 80-ish and earlier CSS transforms were evaluated fully in software mode when blending filters or transparency effects were active, at least on mac os.

[afavour]

That’s not what I’ve observed. But in any case, the point in the context here is that such CPU usage doesn’t tie up the JS event loop.

[nikisweeting]

Yeah you can do tons of interaction-dependent stuff without losing the GPU-accelerated nature and declarative style of CSS animations.

We built a high performance animation library on this concept: https://github.com/Monadical-SAS/redux-time