by kirupa | 4 April 2015
Today, you have three very distinct approaches for animating things on the web: CSS animations, CSS transitions, and requestAnimationFrame. This distinction is necessary given what each approach does:
It’s interesting to see CSS in a string as a property value be blessed as the official way to do something in an API. (Versus something like CSSStyleDeclaration.)
Looks like all of the concessions made to make this stuff runnable off of the main thread mean that you can’t use this to make dynamic animations, unless you re-apply them constantly, which would defeat the purpose.
What do you mean by dynamic animations? One where you update the values of the animation as it is running?
Yes, I think that’s what I meant. I was keying off your mention of the “main thread”, which to me translates as: there’s a bunch of interdependency between your single main thread of JS and some DOM stuff, or event stuff. CSS animations can be fast in the same sense that separate processes can be fast, or fibers can be fast, or FPGAs can be fast, etc. It’s cool to be fast, but you’re often giving up quite a bit in return.
Yep - that is true! The best you can do, as you suggest, is reset and re-apply the entire animation with a whole new set of values
:: Copyright KIRUPA 2024 //--