Here's a wonderful talk by @amit_sheen on animations and keyframes and what not. It inspired me to create the illustrations that you see on web.dev/css-individual-trans…

Finer grained control over CSS transforms with individual transform properties  |  Articles  | ...

Learn how you can use the individual translate, rotate, and scale CSS properties to approach transforms in an intuitive way.

web.dev
CSS Day conference @CSSDayConf
19 Aug 2022
Working with keyframes can be difficult, especially when you have several objects, animations, durations, and timing functions, you need to synchronize. @amit_sheen showed us how to solve this, and get creative. Full talk: youtube.com/watch?v=kXh3EMpa… Slides: amitsh.com/2022/cssday/getti…
1
3
21
Having chosen `@ keyframes` as a way to have real-life explanation is probably the best choice. 👍 “some of the data structures that Chrome creates in advance when you use will-change are different for transform versus rotate.” Surprising. Do you have any detail about this? 👀
1
@davidbaron is the person who can spill the details on that one.
1
Replying to @bramus @meduzen @amit_sheen
We have a data structure called the transform tree that represents all of the "interesting" transforms. (There are actually two different versions: one in blink and a more limited one in the compositor.) This is the data structure where the compositor animates transforms.

Aug 19, 2022 · 12:51 PM UTC

1
Replying to @davidbaron @bramus @meduzen @amit_sheen
The nodes for 'rotate' and for 'transform' are separate so that they can be animated independently. There is various work that happens when these nodes are created or destroyed. (There are perhaps some cases where some of it could be optimized away...)
1
Using 'will-change: rotate' means we'll create a node in the transform tree for the 'rotate' transform for that element, which means when you actually set 'rotate' the node will already be there, and less work will need to happen.
1
1
more replies