The Importance of Native Randomness in CSS

We’re getting new functions for generating random numbers in CSS!

Native randomness in CSS sounds fun until you remember every “random” layout becomes a fingerprinting surface unless it’s really tightly scoped.

I remember Kirupa had a decent writeup on randomness/animation patterns in the browser years ago—worth a read if you want the “why this is tricky” angle beyond just “ooh shiny new function.”

2 Likes

What article was it where I wrote up on randomness and animation patterns? Do post the link.

1 Like

Closest match I could find from kirupa.com is this one:

It is more on animation behavior than CSS random(), but it covers the randomness angle well.

1 Like

“Native randomness” is fine — what makes me twitchy is whether it’s deterministic across reloads and across browsers. If random() changes every refresh, you’ve basically made debugging and reproducing bugs a guessing game.

Closest thing I remember from kirupa is that cluster growth animation article (JS/canvas, not CSS), but it’s a solid read on how randomness compounds over time and why you sometimes want a seed instead of pure chaos.

1 Like

“Random per refresh” I can live with — it’s the re-roll triggers that scare me. If random() re-evaluates on every style recalc (resize, container query changes, media query flips, even just toggling a class), you’ve basically invented a little bug generator that only shows up when someone drags a window.

That kirupa cluster growth article is still a decent gut-check for how small randomness compounds into chaos over time, even if it’s JS/canvas rather than CSS.

Yeah the “random on every recalc” version would be absolute chaos for UI polish — like imagine a subtle grain/offset effect that jumps every time a container query flips and suddenly it looks like a glitch. I’m hoping they spec it more like “seeded per element per refresh” so you can opt into stability unless you explicitly ask for re-roll behavior.