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
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.
1
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
Replying to @davidbaron @bramus @meduzen @amit_sheen
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.

Aug 19, 2022 · 12:53 PM UTC

1
1
Replying to @davidbaron @bramus @amit_sheen
Does it also mean that what ends up computed in a `matrix()` is converted to single transform nodes and not the other way around? So, when you write `transform: [multiple props]`, it first becomes `matrix()` (according to “computed styles” in dev tools), then a transform tree?
1
The entire value of the 'transform' property (even if it's 'matrix() rotate() scale() matrix() matrix() perspective()') ends up as a single transform node in this tree. The things that have separate nodes are the 'rotate'/'translate'/'scale' *properties* (not *functions*).
1