A practical guide to CSS transitions and animations
blog.prototypr.io
A practical guide to CSS transitions and animations
1–10 of 44 posts
Re: A practical guide to CSS transitions and animations
#2Wonderful 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
Re: A practical guide to CSS transitions and animations
#3And 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...
Re: A practical guide to CSS transitions and animations
#4Wonderful 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
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.
Re: A practical guide to CSS transitions and animations
#5The most important thing to remember when working with animations is the following:
@media (prefers-reduced-motion: reduce) {}
Re: A practical guide to CSS transitions and animations
#6And 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...
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...
Re: A practical guide to CSS transitions and animations
#7Wait, 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?
Re: A practical guide to CSS transitions and animations
#8And 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...
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...
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.).
Re: A practical guide to CSS transitions and animations
#9Earlier quoted context omitted.
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...
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.).
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.
Re: A practical guide to CSS transitions and animations
#10CSS 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.