6 ms·

A practical guide to CSS transitions and animations

267 points by tellmewhyfirst 7y ago

kickopotomus 7y ago
Wonderful article. I hate to be a pedant but you have a typo that detracts some attention because it is in the opening paragraph. > I mean, does anybody really enjoys a stiff, snappy UI? enjoys => enjoy
- ASalazarMX 7y ago
  Typo aside, I greatly prefer a stiff, snappy UI. These kinds of animations look nice and smooth at first, but get in the way after a while. I just want to type some text and check a few boxes, not wait for animations to finish so the UI is responsive again.
  - robocat 7y ago
    Some animations really help usability. I use a programme picker that is a poor Netflix clone. Selecting down to the next row is immediate, and selecting right for the next show within a row also immediately jumps. Vertical and horizontal smooth scrolling (a type of animation) would improve the UI (caveat: unless too slow of course).
    - orhmeh09 7y ago
      Could you tell me how?
      - robocat 7y ago
        Three animations I have implemented: 1. bounce of badge when message received and badge number increases (no sound). A la Mac. 2. After modality viewing item in list on mobile, when returning to list highlight the item to show what you have just edited (easy to lose place, animated highlight helps show new summary). 3. On closing a drawer, animate the closing so you don't lose view of next item. I loath animations (and I really loath coding them) but I will use them if I think it improves the UI, if they are fast, and I don't use them for "design" (I'm an engineer not a designer!).
  - zeta0134 7y ago
    The counter intuitive thing to keep in mind here is that the best animations are subtle, and very quick. There's a balance to strike, but good animation can make the snappy UI give just the tiniest hint of motion and smoothness, without detracting from the experience at all. Animations are meant to be subtle hints to guide the viewers eye, not flashy eye candy. Long animation times are _such_ a common rookie mistake, because the UI dev (or their manager) wants to notice the animation, when in the vast majority of cases, it would be better for the animation to be nearly invisible.
    - tenaciousDaniel 7y ago
      IMO animation should only be used in cases where the change of state is inherently difficult to understand. Animations help users understand what happened after an action.
- tellmewhyfirst 7y ago
  Fixed! Thank you
dmitriid 7y ago
And then you try implementing any of them and realise that even the simplest examples often break in subtle and not-so-subtle ways, have hidden and not-so-hidden restrictions, may or may not be hardware accelerated, may or may not break layout, cause reflow and/or repaint, can't be stopped once started...
- dmitriid 7y ago
  My favourite example is, of course, animating height: auto and width: auto. A detailed discussion on why it's not possible and the (rather insane) tricks you have to do to animate these two properties is here: https://css-tricks.com/using-css-transitions-auto-dimensions/ https://css-tricks.com/using-css-transitions-auto-dimensions...
  - XCSme 7y ago
    You should only animate GPU-accelerated properties (transform, opacity) if you care about performance and responsiveness, or in the worst case some properties that trigger paint (color, backgroundColor, etc.).
    - dmitriid 7y ago
      That's what I (sort of) learned the hard way :) So most useful animations like the collapsing list item in the article are nigh impossible in CSS.
      - XCSme 7y ago
        That's true, there are some limitations. Sometimes you can still do those sort of things in CSS if you set the target values using JS (instead of changing height to 0, change scaleY to 0 and translate up the elements from below with the height of the element that was removed). If all elements are same height, or the height is known beforehand you can just hardcode that translate value into the animations.
        7y ago
Raphmedia 7y ago
The most important thing to remember when working with animations is the following: @media (prefers-reduced-motion: reduce) {} Animations are fine but they will induce vertigo or nausea for some users. Allowing them to turn them off is a must.
- Forge36 7y ago
  Oh man, I didn't realize this was a thing! Thank you for sharing :)
- topaxi 7y ago
  Reduced doesn't mean none though :)
jrochkind1 7y ago
Wait, is it really true that "ease-out" is intended/best for animating elements moving IN from off screen, and "ease-in" for animating elements moving OUT of screen from on screen? I've been using them opposite/wrong (as their names led me to) all along?
- tellmewhyfirst 7y ago
  The name refers to easing into or out of the animation. You want to ease into an animation for something leaving the screen (train leaving the station) versus one entering the screen (train arriving)
  - jrochkind1 7y ago
    oops.
    - jrochkind1 7y ago
      Few of the explanations of ease-in and ease-out I find on top page of google results even now explain this very well. I wonder how many are getting it wrong.
XCSme 7y ago
CSS animations/transitions are very smooth (opacity/transform) and make it easy to implement really cool effects once you understand how they work. The biggest drawback and problem I encountered is that Chrome is very, very, bad at maintaining rendering quality in certain situations. The problem is not that the element you are trying to animate gets blurry (eg. trying to animate text, it will be rendered on GPU, thus moved to its own layer, it might become blurry sometimes), but the problem is that OTHER elements on the page are affected. Try to scale-in the logo in top left of the page? Great, now the text in right sidebar starts jiggling while the animation is running. Want to turn around an image on hover? No problem, only that the SVG icons on the page now have a line artifact through them. Those issues only happen in Chrome, which seems to try too hard (and to have also tried) to optimize for performance over quality.
- akseln 7y ago
  Whilst I wholeheartedly agree, there is a quick fix for some of the issues: adding the will-change property can significantly improve chrome performance. Especially for animations that might run a lot
  - XCSme 7y ago
    The `will-change` property is just a flag for the browser to move the element to its own layer, it does not fix the rendering issues. I tried all fixes I could find on the internet, nothing worked. Just Google for "blurry animation chrome". Some suggested fixes are: -webkit-font-smoothing: antialised; backface-visibility: hidden; transform: translateZ(0); -webkit-font-smoothing: subpixel-antialiased; But most of the times they don't do anything or just make things worse. The only solution is usually to move your elements fractions of a pixel until Chrome is happy. The problem is that if you have a responsive website (or a container that is scaled with a transform), it's impossible to have all elements pixel-perfect aligned on all resolutions. Although they look fine when rendered normally, when adding animations things will get blurry. And because it does not happen in other browsers, it means it's not a limitation of the GPU or monitor to display sub-pixel content. eg: https://bugs.chromium.org/p/chromium/issues/detail?id=521364 https://bugs.chromium.org/p/chromium/issues/detail?id=521364
notadoc 7y ago
This is cool, but... to say animations and transitions are overused on the web is an understatement. Distracting, annoying, slow, increase webpage resource use, induce nausea in a fair number of users... ask yourself, are they really necessary or do you think they just look "cool"? If it's the latter, probably don't use them.
- Moru 7y ago
  When fonts were new, documents were full of different fonts. Now it is animations on web pages.
  - notadoc 7y ago
    Yea, it's almost always all clutter, kind of reminds me of all the animated gifs jammed onto pages in 1994.
thuganalyst 7y ago
The real question here is how OP's username is green. I tried making a new account and naming it <font color="#ee00ff">accountname</font> but HN doesn't allow characters like '<' so that didn't work.
- jxcl 7y ago
  Accounts newer than 2 weeks show up as green. https://github.com/minimaxir/hacker-news-undocumented#green-usernames https://github.com/minimaxir/hacker-news-undocumented#green-...
- outworlder 7y ago
  > but HN doesn't allow characters like '<' Good thing that it doesn't, otherwise the next deadline would be about XSS injection on Hacker News.
innomatics 7y ago
>does anybody really enjoy a stiff, snappy UI? Yes many do. Especially the snappy part. I've removed a lot of eye candy animations coded by well meaning devs at the request of users who care about nothing more that speed. Animations can be a nice first impression, but if you use the app daily e.g for work or data entry you know how to navigate and you want as close to instant response as possible. Maybe a smart pattern is animate in the early days for new users then transition into a more jarring and snappier world as they become regulars.
- mickael-kerjean 7y ago
  Animation only contribute for slower application when it's not applied correctly. Using it to wait for your data will not get any effect on speed
- colordrops 7y ago
  Another option is to only use animations for intros and tutorials but keep them mostly out of the UI except for quick or informative animations.
- mrob 7y ago
  I've never seen a UI animation that I liked, no matter how "quick" some designer thinks it is. Animations are just avoidable latency. But the nice thing about CSS animations is the "cascading" part. CSS is designed to be overridden, and my browser still fulfills its traditional role of "User Agent". Animations get disabled like every other annoyance. If CSS animations didn't exist then designers would probably find some more obnoxious way to implement them.
jbaudanza 7y ago
Is there a good rule of thumb for how to transition new elements into the DOM? Right now, if I have an overlay, I mount it offscreen, and then do a `setTimeout(..., 0)` callback that transitions the overlay into view. This works, but it seems a little glitchy in some environments. I'm wondering if it's too much to make DOM modification and then trigger a transition in the next tick.
- mickael-kerjean 7y ago
  SetTimeout with 0 is a hack, you should have much better result with requestAnimationFrame when it comes to animate something. Also changing class in your DOM and perform the animation in CSS is the way that works best today. Hopefully this will change when the animation API will have better support from JS: https://developer.mozilla.org/en-US/docs/Web/API/Element/animate https://developer.mozilla.org/en-US/docs/Web/API/Element/ani...
- blinky1456 7y ago
  You mean the element is moved offscreen, and has display: none; applied? And now you want to move it onscreen. Do it entirely css. if you use a have a keyframe animation applied and remove display:none on clicking. The animation will fire immediately. Unlike trying to transition it without using keyframes. example: https://jsfiddle.net/mr029o7h/ https://jsfiddle.net/mr029o7h/ (sorry if its a bit messy haven't done this for a while)
enturn 7y ago
Whenever talking about UI animations it's important to observe the Best Practices for Response Times and Latency [1] especially if the animation is in addition to a network request. Latency over 300ms might result in a degraded user experience depending on the situation. 1. https://github.com/Tendrl/documentation/wiki/Best-Practices-for-Response-Times-and-Latency https://github.com/Tendrl/documentation/wiki/Best-Practices-...
- mrob 7y ago
  >0.2 sec gives the felling of instantaneous response This is obviously false. Ideally test with an Arduino or other hard-realtime capable system, but assuming your computer doesn't have absolutely terrible latency you can still test with it. Disable your compositor if you're using one, and use a low latency terminal with uncapped framerate like xterm. The popular method of running "sleep 0.1" alone is not actually a fair test, because a newline is printed immediately on running the command, so you might just be seeing the flicker and not the latency. A better method is comparing: read -n1 -s -p "Press a key: " ; sleep 0.0; echo -n "0.0" ; sleep 2 ; echo "" read -n1 -s -p "Press a key: " ; sleep 0.1; echo -n "0.1" ; sleep 2 ; echo "" To me the difference is clearly visible.

Wonderful article. I hate to be a pedant but you have a typo that detracts some attention because it is in the opening paragraph. > I mean, does anybody really enjoys a stiff, snappy UI? enjoys => enjoy

ASalazarMX 7y ago
Typo aside, I greatly prefer a stiff, snappy UI. These kinds of animations look nice and smooth at first, but get in the way after a while. I just want to type some text and check a few boxes, not wait for animations to finish so the UI is responsive again.
- robocat 7y ago
  Some animations really help usability. I use a programme picker that is a poor Netflix clone. Selecting down to the next row is immediate, and selecting right for the next show within a row also immediately jumps. Vertical and horizontal smooth scrolling (a type of animation) would improve the UI (caveat: unless too slow of course).
  - orhmeh09 7y ago
    Could you tell me how?
    - robocat 7y ago
      Three animations I have implemented: 1. bounce of badge when message received and badge number increases (no sound). A la Mac. 2. After modality viewing item in list on mobile, when returning to list highlight the item to show what you have just edited (easy to lose place, animated highlight helps show new summary). 3. On closing a drawer, animate the closing so you don't lose view of next item. I loath animations (and I really loath coding them) but I will use them if I think it improves the UI, if they are fast, and I don't use them for "design" (I'm an engineer not a designer!).
- zeta0134 7y ago
  The counter intuitive thing to keep in mind here is that the best animations are subtle, and very quick. There's a balance to strike, but good animation can make the snappy UI give just the tiniest hint of motion and smoothness, without detracting from the experience at all. Animations are meant to be subtle hints to guide the viewers eye, not flashy eye candy. Long animation times are _such_ a common rookie mistake, because the UI dev (or their manager) wants to notice the animation, when in the vast majority of cases, it would be better for the animation to be nearly invisible.
  - tenaciousDaniel 7y ago
    IMO animation should only be used in cases where the change of state is inherently difficult to understand. Animations help users understand what happened after an action.
tellmewhyfirst 7y ago
Fixed! Thank you

dmitriid 7y ago

And then you try implementing any of them and realise that even the simplest examples often break in subtle and not-so-subtle ways, have hidden and not-so-hidden restrictions, may or may not be hardware accelerated, may or may not break layout, cause reflow and/or repaint, can't be stopped once started...

dmitriid 7y ago
My favourite example is, of course, animating height: auto and width: auto. A detailed discussion on why it's not possible and the (rather insane) tricks you have to do to animate these two properties is here: https://css-tricks.com/using-css-transitions-auto-dimensions/ https://css-tricks.com/using-css-transitions-auto-dimensions...
- XCSme 7y ago
  You should only animate GPU-accelerated properties (transform, opacity) if you care about performance and responsiveness, or in the worst case some properties that trigger paint (color, backgroundColor, etc.).
  - dmitriid 7y ago
    That's what I (sort of) learned the hard way :) So most useful animations like the collapsing list item in the article are nigh impossible in CSS.
    - XCSme 7y ago
      That's true, there are some limitations. Sometimes you can still do those sort of things in CSS if you set the target values using JS (instead of changing height to 0, change scaleY to 0 and translate up the elements from below with the height of the element that was removed). If all elements are same height, or the height is known beforehand you can just hardcode that translate value into the animations.
      - 7y ago

Raphmedia 7y ago

The most important thing to remember when working with animations is the following: @media (prefers-reduced-motion: reduce) {} Animations are fine but they will induce vertigo or nausea for some users. Allowing them to turn them off is a must.

Forge36 7y ago
Oh man, I didn't realize this was a thing! Thank you for sharing :)
topaxi 7y ago
Reduced doesn't mean none though :)

jrochkind1 7y ago

Wait, is it really true that "ease-out" is intended/best for animating elements moving IN from off screen, and "ease-in" for animating elements moving OUT of screen from on screen? I've been using them opposite/wrong (as their names led me to) all along?

tellmewhyfirst 7y ago
The name refers to easing into or out of the animation. You want to ease into an animation for something leaving the screen (train leaving the station) versus one entering the screen (train arriving)
- jrochkind1 7y ago
  oops.
  - jrochkind1 7y ago
    Few of the explanations of ease-in and ease-out I find on top page of google results even now explain this very well. I wonder how many are getting it wrong.

XCSme 7y ago

CSS animations/transitions are very smooth (opacity/transform) and make it easy to implement really cool effects once you understand how they work. The biggest drawback and problem I encountered is that Chrome is very, very, bad at maintaining rendering quality in certain situations. The problem is not that the element you are trying to animate gets blurry (eg. trying to animate text, it will be rendered on GPU, thus moved to its own layer, it might become blurry sometimes), but the problem is that OTHER elements on the page are affected. Try to scale-in the logo in top left of the page? Great, now the text in right sidebar starts jiggling while the animation is running. Want to turn around an image on hover? No problem, only that the SVG icons on the page now have a line artifact through them. Those issues only happen in Chrome, which seems to try too hard (and to have also tried) to optimize for performance over quality.

akseln 7y ago
Whilst I wholeheartedly agree, there is a quick fix for some of the issues: adding the will-change property can significantly improve chrome performance. Especially for animations that might run a lot
- XCSme 7y ago
  The `will-change` property is just a flag for the browser to move the element to its own layer, it does not fix the rendering issues. I tried all fixes I could find on the internet, nothing worked. Just Google for "blurry animation chrome". Some suggested fixes are: -webkit-font-smoothing: antialised; backface-visibility: hidden; transform: translateZ(0); -webkit-font-smoothing: subpixel-antialiased; But most of the times they don't do anything or just make things worse. The only solution is usually to move your elements fractions of a pixel until Chrome is happy. The problem is that if you have a responsive website (or a container that is scaled with a transform), it's impossible to have all elements pixel-perfect aligned on all resolutions. Although they look fine when rendered normally, when adding animations things will get blurry. And because it does not happen in other browsers, it means it's not a limitation of the GPU or monitor to display sub-pixel content. eg: https://bugs.chromium.org/p/chromium/issues/detail?id=521364 https://bugs.chromium.org/p/chromium/issues/detail?id=521364

notadoc 7y ago

This is cool, but... to say animations and transitions are overused on the web is an understatement. Distracting, annoying, slow, increase webpage resource use, induce nausea in a fair number of users... ask yourself, are they really necessary or do you think they just look "cool"? If it's the latter, probably don't use them.

Moru 7y ago
When fonts were new, documents were full of different fonts. Now it is animations on web pages.
- notadoc 7y ago
  Yea, it's almost always all clutter, kind of reminds me of all the animated gifs jammed onto pages in 1994.

thuganalyst 7y ago

The real question here is how OP's username is green. I tried making a new account and naming it <font color="#ee00ff">accountname</font> but HN doesn't allow characters like '<' so that didn't work.

jxcl 7y ago
Accounts newer than 2 weeks show up as green. https://github.com/minimaxir/hacker-news-undocumented#green-usernames https://github.com/minimaxir/hacker-news-undocumented#green-...
outworlder 7y ago
> but HN doesn't allow characters like '<' Good thing that it doesn't, otherwise the next deadline would be about XSS injection on Hacker News.

innomatics 7y ago

>does anybody really enjoy a stiff, snappy UI? Yes many do. Especially the snappy part. I've removed a lot of eye candy animations coded by well meaning devs at the request of users who care about nothing more that speed. Animations can be a nice first impression, but if you use the app daily e.g for work or data entry you know how to navigate and you want as close to instant response as possible. Maybe a smart pattern is animate in the early days for new users then transition into a more jarring and snappier world as they become regulars.

mickael-kerjean 7y ago
Animation only contribute for slower application when it's not applied correctly. Using it to wait for your data will not get any effect on speed
colordrops 7y ago
Another option is to only use animations for intros and tutorials but keep them mostly out of the UI except for quick or informative animations.
mrob 7y ago
I've never seen a UI animation that I liked, no matter how "quick" some designer thinks it is. Animations are just avoidable latency. But the nice thing about CSS animations is the "cascading" part. CSS is designed to be overridden, and my browser still fulfills its traditional role of "User Agent". Animations get disabled like every other annoyance. If CSS animations didn't exist then designers would probably find some more obnoxious way to implement them.

jbaudanza 7y ago

Is there a good rule of thumb for how to transition new elements into the DOM? Right now, if I have an overlay, I mount it offscreen, and then do a `setTimeout(..., 0)` callback that transitions the overlay into view. This works, but it seems a little glitchy in some environments. I'm wondering if it's too much to make DOM modification and then trigger a transition in the next tick.

mickael-kerjean 7y ago
SetTimeout with 0 is a hack, you should have much better result with requestAnimationFrame when it comes to animate something. Also changing class in your DOM and perform the animation in CSS is the way that works best today. Hopefully this will change when the animation API will have better support from JS: https://developer.mozilla.org/en-US/docs/Web/API/Element/animate https://developer.mozilla.org/en-US/docs/Web/API/Element/ani...
blinky1456 7y ago
You mean the element is moved offscreen, and has display: none; applied? And now you want to move it onscreen. Do it entirely css. if you use a have a keyframe animation applied and remove display:none on clicking. The animation will fire immediately. Unlike trying to transition it without using keyframes. example: https://jsfiddle.net/mr029o7h/ https://jsfiddle.net/mr029o7h/ (sorry if its a bit messy haven't done this for a while)

enturn 7y ago

Whenever talking about UI animations it's important to observe the Best Practices for Response Times and Latency [1] especially if the animation is in addition to a network request. Latency over 300ms might result in a degraded user experience depending on the situation. 1. https://github.com/Tendrl/documentation/wiki/Best-Practices-for-Response-Times-and-Latency https://github.com/Tendrl/documentation/wiki/Best-Practices-...

mrob 7y ago
>0.2 sec gives the felling of instantaneous response This is obviously false. Ideally test with an Arduino or other hard-realtime capable system, but assuming your computer doesn't have absolutely terrible latency you can still test with it. Disable your compositor if you're using one, and use a low latency terminal with uncapped framerate like xterm. The popular method of running "sleep 0.1" alone is not actually a fair test, because a newline is printed immediately on running the command, so you might just be seeing the flicker and not the latency. A better method is comparing: read -n1 -s -p "Press a key: " ; sleep 0.0; echo -n "0.0" ; sleep 2 ; echo "" read -n1 -s -p "Press a key: " ; sleep 0.1; echo -n "0.1" ; sleep 2 ; echo "" To me the difference is clearly visible.