Native CSS randomness closes a gap that has been open for years. If you wanted an organic, non-uniform layout, the answer was JavaScript or server-side math, so layout logic ended up living in layers of the stack that had no business holding it, usually at a cost to performance.
I have been building WordPress sites since the 4.x days, and I have watched plenty of checkouts and landing pages buckle under creative layout logic. The W3C CSS Values and Units Module Level 5 hands that job back to the stylesheet. If you are still calling Math.random() to set a CSS variable, you are doing work the browser will now do for you.
The deterministic bottleneck
CSS is deterministic by design. Declare a color and it stays that color, and most of the time that predictability is exactly what makes CSS dependable. It gets in the way when you want something looser, like scattered background elements or animation delays that do not line up. Three workarounds have carried that load so far:
- Sass randomization happens at build time, so the values ship frozen into the stylesheet.
- PHP inline styles resolve on page load, then break the moment AJAX brings in new content.
- JavaScript hooks are the most capable and the most expensive. Calculating layout values in JS invites layout shifts and race conditions.
Anyone who read my earlier notes on modern CSS features knows where I land on this: native browser support beats another external library. Randomness in CSS moves the logic into the layout engine, where it belongs.
Refactoring the JavaScript approach
The old version of a scattered gallery usually looked something like this:
// The "Naive Approach" using JS
const items = document.querySelectorAll('.gallery-item');
items.forEach(item => {
const randomRotation = Math.floor(Math.random() * 20) - 10;
item.style.setProperty('--rotation', `${randomRotation}deg`);
});It works, but it is an imperative answer to a declarative problem. Every element added to the DOM means running the logic again. The new random() function keeps all of it inside the stylesheet.
Implementing native CSS randomness
The spec adds random() and random-item(), which the browser resolves at the moment it renders. You define a range and a step, and no JavaScript is involved. The MDN documentation ties this kind of native integration to the Rule of Least Power.
/* The "Senior Approach" using Native CSS Randomness */
.gallery-item {
/* Generates a random rotation between -10deg and 10deg */
transform: rotate(random(-10deg, 10deg));
/* Selects a random color from a predefined list */
background-color: random-item(var(--primary), var(--secondary), var(--accent));
}Tidier code is the small win. The bigger one is that layout decisions stay in CSS, so you skip the state management and mutation observers you would otherwise need just to rotate a few divs.
If this kind of CSS work is eating your dev hours, I can take it on. I have been building WordPress sites since the 4.x days.
What to do with it
CSS has spent most of its life as a passive styling language, and functions like these let it generate layout variation on its own. That is reason enough to stop reaching for JavaScript the moment a design needs a bit of variety. Pull out the old workarounds the next time you touch that code and let the browser handle it.
