CSS Just Learned to See More Colors Than Your Design System Does

Your phone has been able to display colors your design system can't produce since roughly 2017. Nobody on your team decided this was fine. It just never came up, because until this month, CSS itself couldn't reliably talk about those colors either.

On July 17, 2026, the W3C pushed CSS Color Module Level 4 to Candidate Recommendation Draft — the milestone that means the spec is done changing shape and browsers start shipping it for real. Buried in it is the first standardized gamut-mapping algorithm the web has ever had: a defined, interoperable way to say "render this specific color, and if the screen can't show it exactly, here's precisely how to get as close as possible without guessing." Paired with perceptual color spaces like OKLCH and OKLab, and native support for Display P3 and Rec.2020, the spec finally gives designers and browsers a shared, accurate language for colors that go beyond what sRGB — the color space nearly every design system still runs on — can express.

This is not a incremental CSS update. It's the web catching up to hardware that's been sitting in pockets for the better part of a decade, and almost no design system is ready for it.

The Gap Nobody Budgeted For

sRGB was standardized in 1996, calibrated to the CRT monitors of that era. Every hex code, every rgb() value, every design token most teams have ever shipped is expressed in it. Meanwhile, the iPhone has shipped Display P3 support since the iPhone 7 in 2016. Most premium Android displays, current MacBooks, and a growing share of external monitors do too. P3 alone covers roughly 25% more of the visible color spectrum than sRGB. Rec.2020, used in modern video and increasingly in displays, covers dramatically more still.

That gap has existed for nearly a decade with essentially no way to close it in CSS, because there was no standardized method for a browser to take a wide-gamut color and correctly render it — or gracefully degrade it — on a screen that couldn't show the full range. Designers who wanted richer color had to fake it: exporting P3 assets as flat images, hard-coding fallbacks, or simply not bothering, because the tooling gap made "sometimes it looks different depending on the display" too unpredictable to ship. CSS Color Level 4 is the thing that finally makes it a first-class, testable, spec'd behavior instead of a hack.

Chrome's own developer documentation put it more bluntly than most spec announcements bother to: CSS was not high-definition-color-ready, while the displays most people carry, sit in front of, and mount on walls have been HD-color-ready for years. That's a nine-year lag between capability and standard, and it's about to close in the space of a browser release cycle.

Why This Is a Design-System Problem, Not Just a CSS Problem

The instinct is to file this under "developer concern" — a new set of functions (oklch(), color(), color-mix()) that engineers will quietly wire up while designers keep picking hex values in Figma. That instinct is exactly backwards, and it's why this gap is going to sit unaddressed at most companies for another year or two even after browsers ship full support.

A design token isn't just a value — it's a promise about what a color is, consistently, everywhere it's used. Right now that promise is implicitly scoped to sRGB, and nobody wrote that scoping down anywhere. Once oklch() and P3 rendering are live in every major browser, that unstated assumption breaks in one of two directions. Either your brand's signature blue stays capped at what sRGB can produce forever, while every other app on a user's home screen that adopted wide-gamut color looks subtly more vivid and alive next to yours — or someone on your team starts hand-picking richer P3 values for a few components without a system-wide decision, and your product develops color drift between the tokens that got the upgrade and the ones that didn't.

Neither outcome is a rendering bug. Both are governance failures — the predictable result of a color system built with no defined behavior for "what happens when the display can show more than the spec we designed against."

What an Actual Gamut-Aware Token System Requires

Getting ahead of this isn't about redesigning your palette. It's about deciding, deliberately, three things most systems have never had to decide before.

First: which of your tokens are gamut-aware and which stay sRGB-locked. Not every color needs the upgrade — functional grays and most neutral UI chrome will look identical either way, and treating everything as wide-gamut just to be thorough is wasted design effort. Brand colors, accent colors, and anything used at large scale (hero imagery backgrounds, marketing surfaces, data-viz palettes) are where the visible difference actually shows up, and where the decision matters.

Second: what your fallback behavior is for the sRGB-only devices that will exist for years yet. CSS Color Level 4 supports this natively via color() function fallback chains — you can specify a P3 value with an sRGB equivalent that ships automatically to devices that can't render the wider gamut — but that fallback has to be chosen, tested, and approved as a design decision, not left to whatever a browser's default clamping produces. An unreviewed fallback is how you end up with a brand color that looks correct on the design lead's MacBook and slightly wrong on half your user base's Android phones.

Third: how you're going to test this at all. Contrast checkers, accessibility audits, and most design QA tooling were built assuming sRGB. A color that passes every existing check can still look meaningfully different — sometimes worse — once rendered through a gamut-mapping algorithm on a wide-gamut screen. Until design tools like Figma expose gamut-aware previews by default (unclear timeline as of this writing), most teams will need to manually spot-check tokens across an actual P3 display before shipping, the same tedious way early responsive design required manually checking real devices before "just resize the browser" became reliable.

The Systems That Get Ahead of This Now Set the Bar

Nobody is going to notice CSS Color Level 4 the way they noticed, say, a new layout primitive. It's not visible in a changelog screenshot. It shows up as "why does that app's colors feel slightly richer than ours," felt rather than named, by users who couldn't tell you what OKLCH stands for. That's exactly the kind of gap that compounds quietly for two years and then becomes an emergency rebrand conversation, instead of a token audit someone could have run in an afternoon this quarter.

The spec just gave design systems a real, standardized language for color that finally matches what hardware has offered for a decade. The systems that treat that as a prompt to audit their token architecture now are going to look meaningfully more considered by the time everyone else notices the gap exists.

Related reading: Your Color Tokens Pass the Contrast Check and Still Fail 300 Million Users covers the other blind spot in most color-token systems — perceptual accessibility, not gamut. Different failure, same root cause: color tokens built for a spec that stopped matching reality.