Hacker News new | ask | show | jobs
by TekMol 781 days ago

    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 into it?

6 comments

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.

We shouldn't diminish the power of transform here. It's not just one property like opacity. You can animate quite a bit on the compositor with transform
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.)
Yeah true tho I’m referring to the counter being set via the content style, which doesn’t update the DOM as such but does/can change layout
If you’re doing animations in JS, better do it with the Web Animations API since it’s also hardware accelerated.
> 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.

One thing that comes to mind is separation of application logic and presentation. It's easier to read your fetch logic if it doesn't include loader DOM element geometry progress logic (calculating rotation degrees and applying inline styles etc.). I know it isn't popular to keep the chocolate separate from the peanut butter these days, but conventions like this draw hard lines that make it easier to reason about where code will be found and where to put it.
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.
This doesn’t offload work to another thread though. And it’s actually more costly as it trigger style recalculations throughout the tree even when it no-ops.
Just wait until we have WebSockets in CSS!

Jokes aside, CSS is declarative and while there is overlap between problems solvable by JS and CSS, I think that’s only natural.

I’m actually really excited for all the new features added to CSS lately, less interpreted code is better.

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

No user ever asked for any of these APIs or technologies, but that doesn't mean they can't be useful to developers.
How can CSS be abused to invade our privacy?
I can think of a few ways, but here is an example where CSS triggers a request to track a user: https://underjord.io/is-this-evil.html
The reason the server can track who is hovering over links is the browser apparently requests the background image only when the interaction happens. I certainly didn't expect that!

This seems to be an example of browser optimization leaking private information. There's an obvious way to fix that: deoptimize. Instead of lazily downloading resources as they are needed, request all the linked resources when the page loads, and do it only once. Now they can't tell whether the requests were due to user interaction or just normal browser behavior.

I wonder if uBlock Origin can deal with this. I know it's got a lot of options for blocking weird information leaks like this, webfonts being an example. Firefox also has fingerprinting resistance, I wonder if it resists this.