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

31–40 of 44 posts

Re: A practical guide to CSS transitions and animations

#31

Post by mickael-kerjean »

jbaudanza wrote: post #24

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.

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

Re: A practical guide to CSS transitions and animations

#32

Post by colordrops »

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…

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.

Re: A practical guide to CSS transitions and animations

#33

Post by dmitriid »

XCSme wrote: post #21
dmitriid wrote: post #15

Earlier quoted context omitted.

> 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!

Ah! Didn’t think about that :)

Re: A practical guide to CSS transitions and animations

#34

Post by orhmeh09 »

robocat wrote: post #19
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.

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

Could you tell me how?

Re: A practical guide to CSS transitions and animations

#35

Post by akseln »

XCSme wrote: post #10

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…

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

Re: A practical guide to CSS transitions and animations

#36

Post by XCSme »

akseln wrote: post #35
XCSme wrote: post #10

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…

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

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

Re: A practical guide to CSS transitions and animations

#37

Post by topaxi »

Raphmedia wrote: post #5

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.

Reduced doesn't mean none though :)

Re: A practical guide to CSS transitions and animations

#38

Post by mrob »

enturn wrote: post #28

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

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

Re: A practical guide to CSS transitions and animations

#39

Post by mrob »

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…

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.

Re: A practical guide to CSS transitions and animations

#40

Post by blinky1456 »

jbaudanza wrote: post #24

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.

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/ (sorry if its a bit messy haven't done this for a while)

Post reply on HN