Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A practical guide to CSS transitions and animations

blog.prototypr.io

Post reply on HN
Print view View original

21–30 of 44 posts

Re: A practical guide to CSS transitions and animations

#21

Post by XCSme »

dmitriid wrote: post #15
XCSme wrote: post #12

Earlier quoted context omitted.

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.

> 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 :(

> This will leave a gap below the elements.

Recursively apply same logic to rest of page!

Re: A practical guide to CSS transitions and animations

#22

Post by 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.

Re: A practical guide to CSS transitions and animations

#23

Post by zeta0134 »

ASalazarMX wrote: post #4
kickopotomus wrote: post #2

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

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.

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.

Re: A practical guide to CSS transitions and animations

#24

Post by 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.

Re: A practical guide to CSS transitions and animations

#25

Post by Moru »

notadoc wrote: post #14

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.

When fonts were new, documents were full of different fonts. Now it is animations on web pages.

Re: A practical guide to CSS transitions and animations

#26

Post by gwillz »

XCSme wrote: post #8
dmitriid wrote: post #6

Earlier 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.).

It's great until you discover things like position-fixed doesn't work when there's an ancestor with a transform.

https://bugs.chromium.org/p/chromium/issues/detail?id=20574

It's really fun because even a will-change: transform will trigger it.

Re: A practical guide to CSS transitions and animations

#27

Post by jrochkind1 »

tellmewhyfirst wrote: post #13
jrochkind1 wrote: post #7

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?

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)

oops.

Re: A practical guide to CSS transitions and animations

#28

Post by 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-...

Re: A practical guide to CSS transitions and animations

#29

Post by tenaciousDaniel »

zeta0134 wrote: post #23
ASalazarMX wrote: post #4

Earlier quoted context omitted.

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.

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,…

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.

Re: A practical guide to CSS transitions and animations

#30

Post by mickael-kerjean »

innomatics wrote: post #22

>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 patte…

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
Post reply on HN