After an interesting and occasionally challenging time with Codecademy’s “Learn CSS: Flexbox and Grid” course, I followed their recommended CSS curriculum onward to “Learn CSS: Transitions and Animations“. It was an interesting and worthwhile unit, and thankfully shorter than the previous course on flexbox + grid. This is in part helped by a narrower scope: the CSS animation system does not attempt to cover all possible animations anyone may want to put on screen. It only animates a specified subset of CSS properties, but doing so covers majority of animation effects useful for adding visual interest and improving the user experience. As opposed to early HTML
<BLINK>, a design misstep which definitely did not improve user experience.
Every animation system shares some fundamentals: what to change, where+when to start, where+when to stop, and how to move between start and stop points. That’s quite a few parameters to change and managing them quickly becomes cumbersome as the number of adjustable knobs increase. But CSS animation has a narrow scope, limiting the complexity somewhat. It also has a benefit: the start and stop state are specified by existing CSS mechanisms, leaving the transition system to deal with the animation-specific parameters.
This actually plays into an advantage of using CSS shorthand, which usually annoys me as presenting multiple ways to describe the same thing. Here multiple transition parameters can be collapsed into a single
transition. It has all the annoyances of shorthands: it is another way to describe the same thing, and it requires memorizing an arbitrary order of parameters. But here
transition has an advantage. We have the option to list multiple transitions in a comma-separated list and they will all execute simultaneously when triggered. The course called this “chaining” animations. I don’t know if the word “chain” was part of CSS specification or just a word choice by the author of this Codecademy course, but I found it misleading because “chain” implies animations that run consecutively (one after the other) instead of all animations running simultaneously in parallel.
Another way to specify multiple animations that run simultaneously is to specify “all” as the animated property. (The “what to change” parameter.) This would apply the same animation duration, easing function, and timing delay to all transitions that apply to an element. This is possible because the start & stop states were specified elsewhere in CSS. I see this as a very powerful mechanism in an “easy to shoot myself in the foot” kind of power. By specifying “all” we commit to animating all applicable property changes now and in the future. Which certainly means surprising behavior in the future when we add another change then surprised to see it animate. Followed by a debugging session that ends with “Oh, this transition applied to ‘all’.”
One thing I did not see is a way to create animated transitions between different layouts, for example when triggered by mechanisms covered in the CSS Responsive Design course. Perhaps that is not a scenario the CSS people deemed important enough?