Recently, I published a story about the new random functions that have landed in CSS and how they work. In this article, we’ll explore the challenges of randomness in CSS, how the concept has evolved over time, and why this native feature is a big deal.
One of the first things I wanted to do when I started developing websites was create unique experiences that changed from person to person. Just little things: a random background here, random colors there… Even small micro-interactions, like confetti or falling snow, needed some level of randomness to feel natural.
And I was not alone! I soon discovered that many web developers (“webmasters,” at the time) wanted to do things like that: adding wow factors and a sense of uniqueness to their sites. But we had a problem: CSS.
CSS is a declarative and deterministic language. Two characteristics that clash with the idea of natural variation:
- Declarative means that it focuses on the what, not the how. In contrast to imperative languages, developers using CSS tell the browser what the expected result is, but not how to achieve it.
- Deterministic means that for a given input we will get the same output. Always the same. If you specify that a color will be red, that color will be red, not blue or yellow.
This is by design, and it’s one of the things that makes CSS predictable and reliable. If you understand how the layout engine works, you can tell which styles will be applied at any given time. Which is great… but not so great if you want to generate random content.
And so began a challenging (and sometimes tortuous) journey for designers and developers to achieve natural variation from a deterministic system.
The Long and Winding Road to Random Styles
The path to random styles in CSS is paved with multiple attempts and shortcomings. But at every step along the way, developers found new solutions that improved on the previous ones. Even if only a little.
Note: This timeline reflects logical progress more than a strict historical or chronological order.
CSS Pseudo-Randomness and Patterns
We can simulate randomness in CSS by creating patterns. But this is not truly random. The results will always be the same, and sooner or later people will notice the pattern.
One way to create this simulation is by using :nth-child() selectors or by playing with animations. The first method is easy but yields subpar results; the second may trick and impress some people.
Warning: Auto-playing media
Needless to say, these methods are hacks that don’t provide randomization at any level. A human may not be able to precisely predict which value comes next — at least not without some effort — but a machine certainly can.
Pre-Processors to the Rescue
We turned to the next best thing: tooling. In particular, CSS preprocessors such as Sass, SCSS, Less, and the like. These tools include math modules that provide random functions we can use at compilation time.
The key phrase in the previous paragraph is “at compilation time.” Yes, we are generating random values for our CSS properties. But once those values are produced during compilation, they are frozen forever (or until the next compilation, to be more precise). Just like a mosquito stuck in amber.
The values will be random when the CSS is generated, but every time visitors visit or refresh the page, they will get the same ones. To produce new values, we would need to recompile the stylesheets.
This was a baby step toward styling randomization, but there was still a long way to go.
Server-Side Randomness
We moved to the next best thing: using other languages to generate random values and passing them to CSS through HTML. Server-side languages like PHP, Java, ASP, and others were perfect for this task while generating the HTML (or even the CSS itself).
This approach works well: we get new random values every time the page is generated, which usually means every time it is visited or refreshed. We also have full control over the randomization, since we can implement our own functions.
It has shortcomings, too. If new content is added dynamically to the page, it gets stuck with the “frozen” values generated during the initial page load. Better than patterns, better than preprocessors… but still not perfect.
This limitation became an even bigger problem with the rise and widespread adoption of single-page applications and client-side JavaScript architectures.
And JavaScript… Finally!
With the proliferation of web applications, it made sense to move randomness to JavaScript. The language is already heavily used, and adding a few random functions to the mix doesn’t seem like a big stretch.
And JavaScript finally solved it! For the first time, styles could actually behave with natural variation: random on creation, on refresh, and even on mutation.
It can be done in many ways, too: using frameworks, CSS-in-JS libraries, or plain vanilla JavaScript. The methods to incorporate styling through this language are vast and well supported. There are some performance and complexity concerns, but JavaScript gets the job done.
We finally had true randomization in web styles… just not in CSS itself.
A Web Problem, and a Web Solution
That last part is important. We have randomization on the web (JavaScript gets the job done) but something feels off. Something doesn’t quite feel right. At its core, that discomfort comes from two things:
- We are applying an imperative solution to a declarative problem.
- We are moving layout decisions from CSS to JavaScript.
An Imperative Solution to a Declarative Problem
We mentioned earlier that CSS is a declarative language that focuses on the what, while JavaScript is an imperative language that focuses on the how.
By moving randomization to JavaScript, we are trying to answer a what question with a how answer. It works, but it’s not ideal.
Using JavaScript, we finally achieved style randomness at all levels: when the page is created, when it is refreshed, and when elements are added or changed (mutation). But in doing so, we are breaking the model.
CSS handles layout, and JavaScript handles logic. We solved a CSS limitation by moving layout decisions into JavaScript, creating a mismatch that produces that subtle “this isn’t quite right” feeling — even when everything technically works.
The CSS Solution
The solution to this model mismatch is simple: move randomization to CSS. Solve a layout problem directly in the layout layer instead of delegating it to a different tool or language. And this happened with the introduction of two new random functions as part of the CSS Values and Units Module Level 5:
random(): generates a random value between a minimum and a maximum.random-item(): selects a random value from a given list.
This approach also aligns with the Rule of Least Power, which suggests choosing the least powerful language suitable for a given purpose. In practice, this means solving a problem using the least powerful language capable of expressing and solving it.
Usually, that language will be better suited to the task. Its features will be adapted to the level at which they are applied, making them simpler, more efficient, and better performing. While a more powerful language can certainly do the job, it often introduces an unnecessary layer of complexity and abstraction.
On the web platform, we have HTML for structure (least powerful), CSS for styling and layout (more powerful), and JavaScript (significantly more powerful). By implementing randomization in CSS, we move the solution to the appropriate layer while also following the Rule of Least Power.
And that’s one of the reasons the new random CSS features are such a big deal… and why they represent something much bigger than just another feature.
The Big Deal
CSS has always been deterministic by design, and native randomness breaks with that tradition. It isn’t just another feature, it represents a shift in how we think about CSS as a language and about the web platform itself.
For the first time, CSS can model natural systems with variation directly: no hacks, no tools, no outsourcing layout decisions to other languages. Randomization takes an honored place in the styling layer, where it always belonged.
This unlocks creative possibilities: generative layouts, organic patterns, playful micro-interactions, and design systems that feel alive and unique. But it also restores architectural clarity: each layer of the web once again does the job it was designed for.
With this change, CSS moves from being purely a styling language toward becoming a generative layout system. It is no longer just a passive actor in web development; it becomes an active participant in the rendering process, defining a space of possible outcomes that the browser resolves into a concrete page.
And that’s the real big deal. Native randomness isn’t just about making things look different; it’s about making the platform more coherent and expressive.
It’s also a reminder that CSS is still evolving, and that sometimes the features people overlook can reshape how we think about a language, and what we imagine is possible on the web.
The Importance of Native Randomness in CSS originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
