One crucial thing that this article misses out is a key way in which Firefox is currently better than all other production browsers: its WebRender renderer (incubated in Servo), where everything is rendered on the GPU. This is enabled for most users, but not all yet because GPUs and GPU drivers are amazingly bad.
Properties like background-color are not expensive to animate, the same cost as properties like transform and opacity.
The “curious little imperfection” of text rendering changing slightly simply doesn’t occur.
will-change is obsolete, effectively becoming a noop.
Properties like margin-top and top can animate just as smoothly as a transleY transformation. (And it will be calculated subpixelly, though Firefox deliberately still snaps both to pixels, yet a little differently for nuanced layout reasons; so there can still be a very subtle difference between the two, and it’s definitely browser-dependent. But most of the rendering difference between the two in non-Firefox browsers is categorically a bug, not a feature.)
It would be good to get all of this mentioned. There are a couple of other related simple factual errors, such as “One is done using margin-top, so it can't be hardware accelerated.”—margin-top can be as hardware accelerated as everything else.
But this is my only quibble with the article at this time. The rest is excellent. I was even getting near the end, worried that hover infinite loops wouldn’t be mentioned, but the doom flicker is there. Good stuff.
>Properties like margin-top and top can animate just as smoothly as a transleY transformation.
Interesting, I always thought that because margin changes the layout it triggers the associated recalculations thus is slower than translate which doesn't
Oh, in absolute terms it’s definitely slower in that way, but the other thing to realise is that layout is cheaper in Firefox than in other production browsers on most computers, because of other parts of Servo that have been landed, such as the CPU-parallelised CSS engine. (Servo CPU-parallelises all of layout, but I don’t think Firefox has adopted that yet.)
The consequence is in many cases the cost of layout is still negligible, and it can keep going smoothly.
The situation on animating things like margin-top and height is pretty much this: (a) under the old regime, jank was pretty much guaranteed; (b) in Servo, it’s actually pretty hard to cause jank—you’ve got to have a significant number of layers, many more than the typical page will have; (c) Firefox is in between, that if your layers aren’t too complex you will probably avoid jank.
(Please note that I’m not encouraging animating layout-affecting properties needlessly; you should almost certainly animate a transformation instead, because it requires strictly less work to be done. But on the other hand, if you have `position: absolute`, it’s cool to know that adjusting `top` (with unconstrained `bottom`) will perform as well as a translateY transformation under WebRender.)
I had a side project that I was desperate to get across a finish line, and I rarely do any CSS at a day job, so I hired a freelancer just to help me get a few CSS issues fixed. One of the things he did was add a few CSS transitions, and the smallest transitions can turn a boring, static site into feeling slick and modern. Simple things like just having elements fade in a little when they appear make a huge visual difference.
As someone who's very far from a talented designer, I realized, transitions are such great value. You can learn a few CSS transition tricks and elevate the perceived design skill of your project greatly relative to the effort spent on learning them.
IMO animations are a hurdle more than an aid. macOS has so many long animations that it takes everything longer. 300ms might not be long, but it adds up. For first few times, animations are cool. But the novelty wears off when you need to do the same action 80th time.
Animations regardless of the domain should be used extremely sparingly. It’s appalling that JS frameworks such as Svelte has this built in. It’s only going to encourage more animations.
I can only imaging how much faster macOS would feel if for example exposè had no animation. Forget about better processors and GPU, the easiest way to make the entire OS faster by 500% would be to turn off all animations. Unfortunately, Apple doesn’t allow us. Even accessibility settings for “reduce motion” just uses fade-in/out animation instead. I really don’t buy the arguments for animation “it gives context to where things come from and where they pop out”. I find that disputable, sure good for initial familiarity but painful the second time.
> Animations regardless of the domain should be used extremely sparingly.
Agreed. I once heard the expression "animations should be felt, not seen." This really resonated with me. For example, dialing the transition time down to 30ms gives the user the experience of something vanishing or the color immediately changing, but the effect is to soften what is otherwise the jerky immediacy of computers.
You can change the animation time from the terminal [1]. There was some awesome list on GitHub that had a nice script that changed most system animation to a minimum, but I can’t find it right now.
I also think the way Apple handles animations gives people a sense of the OS being more organic and friendly and less technical and difficult. In the past, they did that with skeuomorphism, but people are more OK with their phone being a technical device. Still, they're continuing to communicate the underlying concept is that everything has a LOCATION. So menus move in from off-screen, they don't just fade in from thin air. Unused UI-elements move off-screen as well, so they're not gone, they just moved outside your view. The Dock is another great example of this, as well as the animations for opening apps or three-finger swiping between full-screen apps. I believe this makes users less confused and more confident in their ability to use the system. It is also important that Apple is very specific about which speeds and accelerations elements move at, adding to the organic feel and making the OS feel more polished.
Apple's big strength is to make people feel safe and welcome in their ecosystem, and they target people who are willing to pay more for that experience.
Ha, no I meant the opposite -- people buy for the fancy transitions. They want a modern desktop. Also thin looks good in the store. so does a glossy display.
I don’t think you could get a better written article and demos here. Excellent job, a true piece of art.
I think a second part or another thing to talk about that is often missed is weirdness with nested element transitions and inherited transitions on elements. Can be a bit to wrangle for beginners and get to feel smooth.
Besides that, thanks for the resource. I will point this to many!
I agree. This is a great piece of writing and presentation. I'm not a developer, have only dabbled in HTML and CSS as a hobbyist, and probably will never use CSS transitions. But I really enjoyed reading the article, and I'm almost tempted to sign up for his course.
When he has time and feels ready, he should write an article about how to plan and write explanatory articles. People in many fields could learn from him.
"Properties like margin-top can't sub-pixel-render, which means they need to round to the nearest pixel, creating a stepped, janky effect. transform, meanwhile, can smoothly shift between pixels, thanks to the GPU's anti-aliasing trickery."
This is a Chrome-case, Firefox (on Windows) aligns both cases to the pixel grid.
Josh, been really appreciating the quality of your posts.
Enjoy how you break down what's happening and also throw in some "fun facts" of the reasons why something came to be.
Like the will-transform property, have always used it but didn't realize it came out of people hacking the transform3D property to get GPU acceleration
I dislike the will-change property and wish they’d left it at the obviously-a-hack `transform: translateZ(0)`, because the whole thing should simply not be necessary—everything should be rendered on the GPU, and that’s the clear way forward; formalising the will-change property legitimised the prevailing architecture at a time when Servo had already demonstrated with WebRender that it was possible to do better; and so Firefox now uses WebRender and does all rendering on the GPU (on most platforms), so that will-change is, I think, simply rendered obsolete (except for platforms that it can’t yet GPU-render on, because GPUs and their drivers are so awful). See https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... for more info on the whole WebRender performance thing.
Nice graphics and all, but he has some weird bug. If you are at a scroll position somewhere in the middle and click the cheeseburger menu (2 lines instead of 3 I will call it cheeseburger) and close the menu again the content in the background will scroll up and then down to the previous scroll position for no good reason.
Ps....The subscribe cta button has one of the nicest designs I have ever seen, wow.
Funny thing, just yesterday happened to use these for React, for the first time.
Initially I tried react-spring, but couldn't get it work its transition without triggering rendering of the enclosing component way too many times, and what baffled me nondeterministically.
I tried to minimize the problem but it just seemed to be part of it. (native attribute didn't work even with animated.div wrapper). Otherwise seemed like a nice animation package.
Ended up using (previously?) official react-transition-group and voila it worked very nicely with a list of tens of items.
Animation can make the UI much more easy to grok for the user.
Delightful article. I only wish I found it the day before I needed to figure CSS animations on my own, not they day after :) This is by far the best piece I found on the subject.
I use visibility instead whenever possible, since visibility can be included directly in a transition property, making it ideal for toggles and modal backdrops.
Properties like background-color are not expensive to animate, the same cost as properties like transform and opacity.
The “curious little imperfection” of text rendering changing slightly simply doesn’t occur.
will-change is obsolete, effectively becoming a noop.
Properties like margin-top and top can animate just as smoothly as a transleY transformation. (And it will be calculated subpixelly, though Firefox deliberately still snaps both to pixels, yet a little differently for nuanced layout reasons; so there can still be a very subtle difference between the two, and it’s definitely browser-dependent. But most of the rendering difference between the two in non-Firefox browsers is categorically a bug, not a feature.)
It would be good to get all of this mentioned. There are a couple of other related simple factual errors, such as “One is done using margin-top, so it can't be hardware accelerated.”—margin-top can be as hardware accelerated as everything else.
But this is my only quibble with the article at this time. The rest is excellent. I was even getting near the end, worried that hover infinite loops wouldn’t be mentioned, but the doom flicker is there. Good stuff.