Bridging the Browser Divide: How a New Polyfill Brings Declarative CSS random() to Life Across the Web

In his book on moral philosophy, How to Be Perfect, Michael Schur—the creator of the acclaimed television series The Good Place—devotes a chapter titled “The Luck of the Draw” to exploring the myth of meritocracy. He argues that individuals frequently underestimate the role that sheer chance plays in their fortunes. A similar element of unpredictability is finding a home in contemporary web design. As digital experiences increasingly adopt controlled chaos—from probabilistic design patterns to generative interfaces—the web ecosystem is beginning to reflect the notion that a webpage can exist in a state of subtle flux, changing each time a user lands on it.

Yet bringing nondeterministic design to the web has historically meant relying heavily on JavaScript. Now, an emerging standard aims to bring controlled randomness directly into CSS, allowing developers to create probabilistic layouts declaratively. While Apple’s Safari took the lead in implementing native CSS random() support in late 2025, other major browsers have yet to follow suit. To bridge this cross-browser divide, web developers are turning to client-side polyfills that simulate the proposed specification without sacrificing forward compatibility.

Real-world use cases for randomness

In modern web development, the demand for controlled randomness often surfaces in greenfield projects and user experience experiments. Whether it is a burst of branded confetti celebrating a user’s action or subtle variations in background illustrations, introducing unexpected presentational details can make digital products feel more engaging.

However, implementing these features purely in JavaScript often introduces friction. Simple visual flourishes can quickly devolve into complex custom implementations when branding requirements dictate fine-grained control over particle distribution, trajectory, or color palettes. This tension highlights a recurring challenge in frontend development: balancing the desire for dynamic, chaotic visual effects with the need for strict engineering control.

For years, the standard approach required bundling heavy JavaScript libraries or writing custom scripts to manipulate the Document Object Model (DOM) or canvas elements. Front-end engineers have long argued that purely presentational randomness belongs in the presentation layer itself. By bringing randomness into CSS, developers can adhere to the Rule of Least Power—a core principle of web architecture which suggests solving problems using the least powerful language capable of expressing the solution.

The web standards community has consistently sought to standardize common user interface patterns into declarative CSS rules. In late 2025, Apple made a significant leap by introducing native support for the CSS random() specification in Safari 26.2. The update emphasized letting developers tackle widespread design patterns using HTML and CSS alone, paving the cowpaths of existing design practice and reducing dependencies on third-party frameworks.

Following Safari’s release, developers showcased fine-grained control over complex visual effects using native CSS functions alone. Prominent frontend engineers noted that CSS provides an ideal environment for managing presentational randomness, avoiding the overhead and potential performance bottlenecks associated with continuous JavaScript execution.

Despite the enthusiasm surrounding Safari’s implementation, cross-browser adoption remains incomplete. Half a year after Safari introduced native CSS random(), neither Google Chrome nor Mozilla Firefox has shipped a production-ready implementation, even behind experimental browser flags. While issue trackers for both browser engines indicate active development, developers remain without a clear timeline for baseline cross-browser support.

This discrepancy leaves developers facing a familiar dilemma: wait years for baseline browser availability or rely on client-side workarounds. Moreover, because Safari updates are tied to Apple’s operating system release cycles, even a portion of iOS and macOS users remain on older versions that lack native support.

Polyfilling modern CSS features presents significant architectural challenges. Unlike JavaScript polyfills, which can easily patch global objects or prototype methods, CSS polyfills often require fetching external stylesheets, parsing non-standard syntax at runtime, and manually rewriting the CSS Object Model (CSOM)—processes that can introduce performance overhead and layout shifts.

To overcome these obstacles without waiting years for full browser convergence, open-source maintainers have released utility packages like css-random-polyfill. By leveraging CSS custom properties as a clean abstraction layer, developers can begin writing declarative random values today while maintaining a seamless upgrade path for when native support arrives across all major engines.

Demo: Random starfield

To demonstrate how a polyfill can achieve cross-browser parity for CSS random(), consider a classic presentational effect: a dynamic starfield consisting of scattered, twinkling stars fading in and out at unpredictable intervals.

In a purely native Safari environment, CSS random() functions can be written directly within standard declarations. To make the code function across non-supporting browsers like Chrome and Firefox, the polyfill relies on a lightweight script combined with a marker class on targeted DOM elements.

<!-- The polyfill script processes CSS random calls on load -->
<script src="https://unpkg.com/css-random-polyfill@latest/dist/css-random-polyfill.js"></script>

<!-- Elements marked with the "randomized" class are processed by the polyfill -->
<div class="randomized star"></div>
<div class="randomized star"></div>
<div class="randomized star fourpointed"></div>
<div class="randomized star fourpointed"></div>

On the styling side, instead of writing random() directly inside standard CSS properties, the polyfill requires storing intermediate values inside CSS custom properties prefixed with --random. Because arbitrary custom property syntax is technically valid in all modern browsers, the code parses safely without throwing CSS syntax errors.

.star 
  --random-star-size: random(1px, 7px, 1px);
  background-color: white;
  border-radius: 50%;
  aspect-ratio: 1/1;
  width: var(--random-star-size);
  position: fixed;

  --random-top: random(0%, 100%);
  --random-left: random(0%, 100%);
  top: var(--random-top);
  left: var(--random-left);

  --random-hue: random(0, 360);
  filter: drop-shadow(0px 0px calc(var(--random-star-size) * 0.7) oklch(0.7 0.2 var(--random-hue)))
    drop-shadow(0px 0px calc(var(--random-star-size) * 3) white);
  mix-blend-mode: hard-light;

  --random-speed: random(2s, 5s);
  animation: fade-in var(--random-speed);
  animation-iteration-count: infinite;

  --random-delay: random(2s, 5s);
  animation-delay: var(--random-delay);
  animation-direction: normal;

This starfield example illustrates key features of the current random() specification. For instance, the function supports an optional third parameter representing a step interval, restricting the generated values to specific step increments:

--random-star-size: random(1px, 7px, 1px);

The specification also introduces the element-shared keyword, ensuring that every element sharing a particular class evaluates the function to the same randomized value. In the starfield demo, this allows all four-pointed stars to tilt at identical, randomly selected angles:

.star.fourpointed 
  --random-rotation: random(element-shared, -45deg, 45deg);
  rotate: var(--random-rotation);

While using intermediate custom variables requires slightly more setup than native inline calls, it ensures full backward compatibility. Once native engine support reaches universal baseline, developers can simply remove the polyfill script reference, leaving behind valid, native CSS code.

Demo: Random Colored Grid Cells

Beyond atmospheric background particle effects, declarative randomness provides practical benefits when constructing structured CSS Grid layouts. In experimental demonstrations, developers have used CSS random() to auto-generate randomized multi-colored grid structures without manual JavaScript intervention.

The polyfill handles nested expressions and dynamic custom variable references seamlessly. For instance, developers can pass CSS custom properties directly into the random() function or combine multiple randomized function calls inside shorthand properties like grid-area:

.rectangle 
  --random-grid-area: random(1, var(--rows), 1) / random(1, var(--columns), 1);
  grid-area: var(--random-grid-area);

This approach allows grid items to automatically assign themselves to randomized starting rows and columns, offering a declarative way to build generative art or dynamic dashboard previews.

Demo: Wheel of fortune

Another compelling use case involves physical simulations and game UI elements, such as a spinning wheel of fortune. Originally showcased by engineers on Apple’s WebKit team, this layout demonstrates how CSS calculations can reconcile mixed measurement units within a single random function call.

@keyframes spin 
  from 
    rotate: 0deg;
  
  to 
    rotate: var(--random-rotation);
  


#wheel 
  --random-rotation: random(2turn, 10turn, 20deg);

The specification permits mixing different measurement units—such as turns (turn) and degrees (deg)—provided they resolve to the same underlying data type. CSS typed arithmetic handles the conversion automatically, allowing step intervals defined in degrees to operate seamlessly over a range specified in turns.

Under the current polyfill architecture, static properties are computed once during the page’s initial render. While full native implementations will ultimately support dynamic re-evaluation during keyframe animations or interactions, initial-load computation provides a lightweight solution for static visual setups.

Demo: Random squares

To demonstrate value sharing across multiple layout dimensions, simple geometric tests show how custom key identifiers can synchronize random numbers across separate CSS rules.

--random-height: random(--side, 40px, 100px);
--random-width: random(--side, 40px, 100px);

width: var(--random-height);
height: var(--random-width);

By providing a custom identifier key (such as --side), the CSS parser guarantees that both the height and width evaluate to the exact same generated length, forcing each target element to maintain a perfect square aspect ratio despite varying dimensions across elements.

Chromium-only bonus demo: Simulate random-item using a custom CSS function

While numeric range generation solves many presentation requirements, developers frequently need to select randomly from a discrete list of explicit values—such as picking a brand color from an established palette. To address this, the W3C CSS Values and Units Module Level 5 draft proposes a dedicated random-item() function:

random-item(element-shared, red, blue, green);

Because random-item() remains largely unimplemented in shipping engines, developers experimenting in Chromium-based browsers can simulate list-selection behavior by combining css-random-polyfill with emerging CSS features like custom CSS functions (@function) and inline style conditionals (if()).

--random-index: random(element-shared, 1, 5, 1);
--random-color: --item(var(--random-index), aqua, purple, pink, grey, green);

By crafting a custom generic lookup function, developers can map a randomly generated integer index to an arbitrary list of default arguments:

@function --item(--index,
  --arg-1: ,
  --arg-2: ,
  --arg-3: ,
  --arg-4: ,
  --arg-5: ,
  --arg-6: ,
  --arg-7: ,
  --arg-8: ,
  --arg-9: ,
  --arg-10: ) 

  result: if(
    style(--index: 1): var(--arg-1);
    style(--index: 2): var(--arg-2);
    style(--index: 3): var(--arg-3);
    style(--index: 4): var(--arg-4);
    style(--index: 5): var(--arg-5);
    style(--index: 6): var(--arg-6);
    style(--index: 7): var(--arg-7);
    style(--index: 8): var(--arg-8);
    style(--index: 9): var(--arg-9);
    else: var(--arg-10);
  );

Unlike historical workaround scripts that relied on complex color-specific mathematical hacks, custom functions combined with declarative randomness operate cleanly across any valid CSS data type—including colors, lengths, transform matrices, or strings.

How the polyfill works

The core implementation of the client-side css-random-polyfill relies on existing open-source mathematical parsing tools. Rather than building a custom math engine, the polyfill leverages the MIT-licensed @csstools/css-calc package—a dependency-free utility maintained as part of the PostCSS ecosystem that was recently updated to mirror the latest W3C random() specifications.

To bridge build-time evaluation with runtime execution, the client script runs feature detection upon execution. If native support is absent, it scans the DOM for declared target elements and reads their computed style declarations.

import  calc  from "@csstools/css-calc";
const calcFn = calc;

if (!CSS.supports("width", "random(0px, 100px)")) 
  const styleTag = document.createElement("style");
  styleTag.textContent = ".randomized  display: none; ";
  document.head.appendChild(styleTag);
  const elementIDs = new WeakMap();
  const documentID = crypto.randomUUID();

  document.querySelectorAll(".randomized").forEach((element) => 
    const styles = getComputedStyle(element);
    [...styles]
      .filter((property) => property.startsWith("--random"))
      .forEach((propertyName) => 
        const css = styles.getPropertyValue(propertyName);
        const value = resolveRandom(css, 
          element,
          propertyName,
          documentID,
          elementIDs,
          calcFn,
          crypto,
        );
      element.style.setProperty(propertyName, value);
    );
  );
  if (styleTag.parentNode) 
    styleTag.parentNode.removeChild(styleTag);
  


function resolveRandom(css,  element, propertyName, documentID, elementIDs, calcFn, crypto ) 
  const patchedCss = css.replace(
    /random(s*(?!(?:[^,]*b(?:shared

The process operates through clear architectural stages:

First, the script uses CSS.supports() to verify whether the host browser supports native random() declarations. If native evaluation is present—as in modern Safari— execution halts immediately, handing full control to the browser’s engine.

If feature support is missing, the script temporarily applies a hidden display state to marked elements to prevent visual layout shifts during evaluation. It then assigns stable document and element identifiers using crypto.randomUUID() and a WeakMap instance.

Next, the script queries elements matching the designated marker class and inspects their computed styles using getComputedStyle(). It isolates every custom property beginning with the --random prefix.

Finally, the expressions are passed to the calculation engine, which resolves mathematical ranges, applies caching semantics based on property keys, and injects the resulting values directly as inline style overrides. Once processing completes, the temporary hidden style tag is removed.

By leveraging custom properties as the runtime interface, this approach avoids the most hazardous pitfalls of conventional CSS polyfilling. The script never needs to re-fetch network stylesheets or re-parse full CSS documents, delivering a light, predictable execution path.

The path forward for CSS randomness

As frontend development continues to evolve toward declarative, low-code patterns, the introduction of CSS random() marks a major milestone in giving stylesheets direct control over visual variation. While browser parity remains divided, community polyfills offer a practical bridge, allowing engineering teams to experiment with probabilistic design patterns today without locking their codebases into non-standard abstractions.