Oklch is a polar colour space corresponding to the rectangular Oklab, designed as a
perceptual colour space, matching how people see things, rather than how display technology works.
There are three things to consider here:
1. Colour interpolation, as used in things like linear-gradient() and color-mix(). The default of sRGB is not particularly good; choosing Oklab or Oklch instead will normally improve things. Oklch is an okay default these days. I reckon that for most applications, Oklab is better. Oklch tends to be too vibrant in the most extreme cases like #ff0000 → #0000ff. Here’s a simple demo you can play with:
data:text/html,div{width:20em;height:2em;display:flex;align-items:center;justify-content:center;background:linear-gradient(in var(--space) to right,var(--from),var(--to));}document.querySelectorAll("input").forEach(e=>e.onchange())sRGBOklabOklch
2.
Specifying colours that are beyond the sRGB gamut. This is what they say in
https://tailwindcss.com/docs/v4-beta#modernized-p3-color-pal...: “taking advantage of the wider gamut to make the colors more vivid in places where we were previously limited by the sRGB color space”. Frankly, this is seldom actually advisable. For most purposes, sRGB is quite enough, thank you: go beyond it, and your colours will be too vivid. In
photographs it makes sense, but for colour palettes used with blocks of colours and such, it’s normally a bad idea. Yet if you
are trying to go beyond sRGB, meh, nothing wrong with writing it in Oklch. Though color(display-p3 ‹r› ‹g› ‹b›) may be easier to
reason about—
3. Specifying general colours. I’ll be blunt. Perceptual colour spaces are horrible at this. With things like HSL and LCH (and even display-p3 colours), you get values in a known range (e.g. 0–100%, 0–360°, 0–1), and they all work. With things like Oklch, do you know how thin the range of acceptable values is? Just try working with yellow, I dare you, or anywhere at the edges of what things are capable of. As a human, you cannot work with these values. You have to treat them as opaque, only to be manipulated by colour-space-aware tools. To take the most extreme example, take #ffff00, which https://oklch.com/ says is approximately oklch(0.968 0.21095439261133309 109.76923207652135)… whoops, you already slipped out into Rec2020 space. And it goes approximating it to #ffff01, anyway. And fairly minor adjustments will take it out of any current (or probable!) gamut. Just look at the diagrams, see how slim the area of legal values is at this extreme.
Perceptual colour spaces are really good for some things: interpolation, and some data visualisation palette things. But beyond that, you’re in a digital world, and a limited world at that, and they’re actually quite difficult to work with, and you should normally stick with #rrggbb. Especially if you have any interest in working near the maximum of any colour channel.
As an example, look at a place oklch() is used in that document:
--color-avocado-100: oklch(0.99 0 0);
--color-avocado-200: oklch(0.98 0.04 113.22);
--color-avocado-300: oklch(0.94 0.11 115.03);
--color-avocado-400: oklch(0.92 0.19 114.08);
--color-avocado-500: oklch(0.84 0.18 117.33);
--color-avocado-600: oklch(0.53 0.12 118.34);
I don’t know how they chose those numbers, but there’s no low-order polynomial curve there; they seem entirely arbitrary choices. Not a good showing for Oklch. The “modernized P3 color palette” shown is just as bad: all of L, C and H seem arbitrarily chosen. If you’re going to do it like that, you’re completely wasting your time putting the numbers in a perceptual colour space.
To be clear: Oklch is way better than RGB for some things, but it’s downright terrible for some purposes (often because you do actually care about the display technology, rather than a theoretical model of how vision works), and a lot of the claimed benefits for some purposes don’t hold up to real analysis.