6 ms·
An interactive guide to CSS transitions
- prezjordan 6y agoI 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.
- yawaworht1978 6y agoNice 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.
- WORMS_EAT_WORMS 6y agoI 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!
- deleted 6y ago[deleted]
- tailspin2019 6y agoAgreed. This is an exceptional piece of work. Very engaging too. I’ll be referring back to this.
- tkgally 6y agoI 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.
- xbar 6y agoWell said. Cheers, author.
- rajvosa07 6y agoSuper helpful, thanks!
- szopa 6y agoDelightful 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.
- grenoire 6y ago"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.
- alvarlagerlof 6y agoAnimating margin is bad for other reasons too. Transform and opacity is significantly faster.
- grenoire 6y agoSure, you don't want to dirty the layout tree on each frame.
- sevencolors 6y agoJosh, 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
- chrismorgan 6y agoI 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-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... for more info on the whole WebRender performance thing.
- djsavvy 6y agoThat 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?
- chrismorgan 6y agoLooks 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1695431. For now, https://hacks.mozilla.org/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/the-whole-web-at-maximum-fps-how-w... works.
- mushishi 6y agoFunny 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.
- djoldman 6y agoFinally! .btn { will-change: transform; } thanks, man that was annoying.
- chrismorgan 6y agoOne 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.
- iaml 6y ago>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
- chrismorgan 6y agoOh, 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.)
- waprin 6y agoThanks 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!
- deleted 6y ago[deleted]
- jopsen 6y agoI love css transitions, but ending a transition with "display: none" is somehow still a pain.
- ketzo 6y ago"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)
- inopinatus 6y agoI use visibility instead whenever possible, since visibility can be included directly in a transition property, making it ideal for toggles and modal backdrops.
- zodiakzz 6y agoThere's a workaround if you're open to using CSS animations. [1] 1: https://stackoverflow.com/a/9334132 https://stackoverflow.com/a/9334132
- systemvoltage 6y agoIMO 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.
- herrvogel- 6y agoYou 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-animations-mac-os-x/ https://osxdaily.com/2012/02/14/speed-up-misson-control-anim...
- systemvoltage 6y agoThis is long gone. No longer possible.
- _greim_ 6y ago> 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.
- m463 6y agoI 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.
- mraza007 6y agoIn my opinion this was a great guide. I’m someone who sucks at writing transitions in css so this definitely helped
- Lorin 6y agoI had fun clicking random things to hear the noises, noticed them after pressing 'enable tab key' :)
- stvnitt 6y agoIf you like interactive guides like this, I just found this game to better learn flexbox. Surprisingly fun— https://flexboxfroggy.com/ https://flexboxfroggy.com/