Time-Based CSS Animations • Hacker News Board

Re: Time-Based CSS Animations

#11

Post by tuyiown » Sun, May 05, 2024, 8:44 AM UTC

TekMol wrote: post #6

CSS now has enough Math functions supported, particularly mod(), round(), and trigonometric functions CSS can not start a timer like JavaScript does, but nowadays it's possible to define a custom variable with the CSS Houdini API to track time in milliseconds. Why do we need all this when we have JavaScript? Shouldn't the drawing layer be concerned with drawing primitives? Why put more and more of the higher layers i…

> Shouldn't the drawing layer be concerned with drawing primitives?

CSS is not a drawing layer. The drawing is driven by the DOM, either setup by HTML or updated through JS. CSS only piggyback on it by giving parameters to the painting engine about what to do with dom, essentially overriding the defaults parameters. You can add dom blocks, modify positioning behavior with complex algorithms, even margins are not really trivial.

I don't think this is a great solution, but people started this to be able to modify colors during dom rendering without having to update their HTML code, probably because updating HTML code was not fun at all, but I really think the wrong problem was addressed. Those were the «webmaster» times, so there's also that.

Re: Time-Based CSS Animations

#12

Post by mattgperry » Sun, May 05, 2024, 8:48 AM UTC

joestrong wrote: post #10

TekMol wrote: post #6

CSS now has enough Math functions supported, particularly mod(), round(), and trigonometric functions CSS can not start a timer like JavaScript does, but nowadays it's possible to define a custom variable with the CSS Houdini API to track time in milliseconds. Why do we need all this when we have JavaScript? Shouldn't the drawing layer be concerned with drawing primitives? Why put more and more of the higher layers i…

Don't forget that CSS animations are hardware accelerated. If you're doing trig in JS for animations, you're probably also manipulating the DOM to update the UI every millisecond, which is very expensive

Most CSS animations aren't hardware accelerated. Only a few values like opacity and transform.

Updating the DOM (as in innerHTML) is always expensive because it triggers layout. This is true whether you're doing it from JS or a CSS trick like on this page.

Finally this approach is using CSS custom properties. These are slow - slower than JS for most things.

If you stop all animations on this page and profile it via Chrome you can see this in effect. The root node is animating a CSS variable. 117 elements have their style recalculated. Every frame - yet no animations are running. There's also a tiny paint triggered too, obviously there's been no changes so it is tiny in this instance, but a paint is always triggered when a CSS variable updates.

This is why animating x and y separately via CSS and a style like `translate(var(--x) var(--y))` would be worse than animating them via JS ala Framer Motion/GSAP.

Re: Time-Based CSS Animations

#13

Post by silvestrov » Sun, May 05, 2024, 8:53 AM UTC

The animation at the bottom of the page is very impressive. It looks very much like a rather than elements.

Re: Time-Based CSS Animations

#14

Post by onion2k » Sun, May 05, 2024, 8:57 AM UTC

TekMol wrote: post #6

CSS now has enough Math functions supported, particularly mod(), round(), and trigonometric functions CSS can not start a timer like JavaScript does, but nowadays it's possible to define a custom variable with the CSS Houdini API to track time in milliseconds. Why do we need all this when we have JavaScript? Shouldn't the drawing layer be concerned with drawing primitives? Why put more and more of the higher layers i…

Regardless of anything else, JS is a single thread (mostly, there are workers of course) so anything you can do to offload work somewhere else is a good thing for keeping the UI running at a solid frame rate.

Re: Time-Based CSS Animations

#15

Post by chrisjj » Sun, May 05, 2024, 9:24 AM UTC

Interestingly without 'Experimental feature flags' demos before mod() work, though mod() and sin() do nothing - on latest Android Chrome.

Re: Time-Based CSS Animations

#16

Post by agust » Sun, May 05, 2024, 9:45 AM UTC

mattgperry wrote: post #12

joestrong wrote: post #10

Earlier quoted context omitted.

Don't forget that CSS animations are hardware accelerated. If you're doing trig in JS for animations, you're probably also manipulating the DOM to update the UI every millisecond, which is very expensive

Most CSS animations aren't hardware accelerated. Only a few values like opacity and transform. Updating the DOM (as in innerHTML) is always expensive because it triggers layout. This is true whether you're doing it from JS or a CSS trick like on this page. Finally this approach is using CSS custom properties. These are slow - slower than JS for most things. If you stop all animations on this page and profile it via C…

Just one nitpick: the DOM is not updated by CSS here, only the value of the CSS variable is. (It will indeed cause style recalc and paint though, and result in poor performance as we can see with the demos.)

Re: Time-Based CSS Animations

#17

Post by kevingadd » Sun, May 05, 2024, 10:47 AM UTC

GalaxyNova wrote: post #4

Whatever you're doing isn't working on Firefox. Edit: Just read the disclaimer, whoops!

Oddly on my system, it works better in Firefox (it's not animated, but all the elements are there) than it does in Chromium (completely blank where the animated demo should be).

Re: Time-Based CSS Animations

#18

Post by rtcode_io » Sun, May 05, 2024, 11:05 AM UTC

https://RTCode.io, a real-time web playground without reloads (and without state resets) might greatly benefit anyone working with CSS animations/transitions!

Demo on https://RTCode.io

(To import pens, simply replace the hostname with xcodepen.io in your URLs.)

Re: Time-Based CSS Animations

#19

Post by RunSet » Sun, May 05, 2024, 11:13 AM UTC

TekMol wrote: post #6

CSS now has enough Math functions supported, particularly mod(), round(), and trigonometric functions CSS can not start a timer like JavaScript does, but nowadays it's possible to define a custom variable with the CSS Houdini API to track time in milliseconds. Why do we need all this when we have JavaScript? Shouldn't the drawing layer be concerned with drawing primitives? Why put more and more of the higher layers i…

> Why do we need all this when we have JavaScript?

In practice, mostly so google can still invade the privacy of users after they disable javascript.

No user ever asked for this.

Re: Time-Based CSS Animations

#20

Post by keepamovin » Sun, May 05, 2024, 11:52 AM UTC

I wanted this for a while so I could do a 'box-breathing' thing. With the inhale-hold-exhale-hold stages all being customizable to fit your body and go for the effect you wanted.

Could not figure out a way to do it (sans JS or insane complexity) without something like what's on this page. Holy stylesheets! This page has really creative demos!!! Haha :)