An interactive guide to CSS transitions | Hacker News Reader

An interactive guide to CSS transitions

joshwcomeau.com

309 pointstomaszs40 comments

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.)

Thanks so much for this amazing guide!

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.

I'll be using this!

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.

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.

[1] https://osxdaily.com/2012/02/14/speed-up-misson-control-anim...

This is long gone. No longer possible.

> 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.

I wonder if this is like the first someone makes a presentation with powerpoint or makes their first movie with imovie.

Of COURSE they add the fancy scene or slide transitions. (at first)

and then you learn that you should just cut.

Why do you think Apple hasn't learned that? They employ designers, artists and animators with decades of experience.

Similarly, why are experienced designers adding transitions to their site that people wouldn't add in their second or third site build?

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.

Ah, right on! Thanks.

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.

In an ideal world every web app would respect the "prefers reduced motion" CSS rule, and take this into consideration with their front-end. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

Reduced motion != no animations.

Apparently, in MacOS, reduced motion is just the same except it’s a fade animation. More importantly, it takes the same amount of time.

The main reason I activate developer mode on every Android phone I get is because that gives access to the option to globally accelerate animations.

Turning them off entirely is an option but in my experience that can produce a few confusing results. It's livable, though.

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!

Agreed. This is an exceptional piece of work. Very engaging too.

I’ll be referring back to this.

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.

Well said. Cheers, author.

"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.

Animating margin is bad for other reasons too. Transform and opacity is significantly faster.

Sure, you don't want to dirty the layout tree on each frame.

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.

That link to `hacks.mozilla.org` is 404ing for me, and even the link after a quick web search was 404ing. Is there something wrong on Mozilla's end?

Looks like they just now changed their URL format to remove the year and month, and broke all existing links. Bleh. Looks like someone reported this at https://bugzilla.mozilla.org/show_bug.cgi?id=1695431. For now, https://hacks.mozilla.org/the-whole-web-at-maximum-fps-how-w... works.

I wish had both the skill and energy to put the sort of care and attention to detail into my work that Josh does. Really, really great stuff.

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.

If you like interactive guides like this, I just found this game to better learn flexbox. Surprisingly fun—

https://flexboxfroggy.com/

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.

In my opinion this was a great guide. I’m someone who sucks at writing transitions in css so this definitely helped

I had fun clicking random things to hear the noises, noticed them after pressing 'enable tab key' :)

I love css transitions, but ending a transition with "display: none" is somehow still a pain.

"opacity: 0;" if you don't want to actually remove the box from the page

"display: none;" if you do

though as with all things CSS, tends to be a bit easier said than done

(this is sort of a wild shot in the dark guessing at what you're talking about, but I've done a lot of CSS and it feels like a good guess)

I use visibility instead whenever possible, since visibility can be included directly in a transition property, making it ideal for toggles and modal backdrops.

There's a workaround if you're open to using CSS animations. [1]

1: https://stackoverflow.com/a/9334132

Finally!

.btn { will-change: transform; }

thanks, man that was annoying.

Super helpful, thanks!

Reply on news.ycombinator.com