
A practical guide to CSS transitions and animations - tellmewhyfirst
https://blog.prototypr.io/this-aint-disney-a-practical-guide-to-css-transitions-and-animations-a8b87e7c5531
======
Raphmedia
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
Oh man, I didn't realize this was a thing! Thank you for sharing :)

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

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

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

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

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

------
notadoc
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
When fonts were new, documents were full of different fonts. Now it is
animations on web pages.

~~~
notadoc
Yea, it's almost always all clutter, kind of reminds me of all the animated
gifs jammed onto pages in 1994.

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

~~~
dmitriid
> 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

This will leave a gap below the elements

> If all elements are same height, or the height is known beforehand you can
> just hardcode that translate value into the animations.

The problem is that there's rarely if ever a case when you know the height of
all elements on a page :(

~~~
XCSme
> This will leave a gap below the elements.

Recursively apply same logic to rest of page!

~~~
dmitriid
Ah! Didn’t think about that :)

------
enturn
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-...](https://github.com/Tendrl/documentation/wiki/Best-Practices-
for-Response-Times-and-Latency)

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

------
jbaudanza
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
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/ani...](https://developer.mozilla.org/en-
US/docs/Web/API/Element/animate)

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

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

------
thuganalyst
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
Accounts newer than 2 weeks show up as green.

[https://github.com/minimaxir/hacker-news-
undocumented#green-...](https://github.com/minimaxir/hacker-news-
undocumented#green-usernames)

