[HN Gopher] An interactive guide to CSS transitions
___________________________________________________________________
An interactive guide to CSS transitions
Author : tomaszs
Score : 179 points
Date : 2021-02-26 13:27 UTC (9 hours ago)
(HTM) web link (www.joshwcomeau.com)
(TXT) w3m dump (www.joshwcomeau.com)
| grenoire wrote:
| "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 wrote:
| Animating margin is bad for other reasons too. Transform and
| opacity is significantly faster.
| yawaworht1978 wrote:
| 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.
| sevencolors wrote:
| 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
| chrismorgan wrote:
| 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.
| [deleted]
| mraza007 wrote:
| In my opinion this was a great guide. I'm someone who sucks at
| writing transitions in css so this definitely helped
| mushishi wrote:
| 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.
| chrismorgan wrote:
| 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.
| waprin wrote:
| 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!
| prezjordan wrote:
| 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.
| jopsen wrote:
| I love css transitions, but ending a transition with "display:
| none" is somehow still a pain.
| inopinatus wrote:
| I use visibility instead whenever possible, since visibility
| can be included directly in a transition property, making it
| ideal for toggles and modal backdrops.
| ketzo wrote:
| "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)
| rajvosa07 wrote:
| Super helpful, thanks!
| szopa wrote:
| 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.
| WORMS_EAT_WORMS wrote:
| 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!
| tailspin2019 wrote:
| Agreed. This is an exceptional piece of work. Very engaging
| too.
|
| I'll be referring back to this.
| [deleted]
| systemvoltage wrote:
| 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 expose 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.
| _greim_ wrote:
| > 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 wrote:
| 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.
| 1123581321 wrote:
| 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?
| herrvogel- wrote:
| 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...
| djoldman wrote:
| Finally!
|
| .btn { will-change: transform; }
|
| thanks, man that was annoying.
___________________________________________________________________
(page generated 2021-02-26 23:00 UTC)