[atsjie]

They are switching from sRGB to OKLCH.

First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here?

Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.

[kevinsync]

OKLCH is a curve that makes everything look nicer lol

https://abhisaha.com/blog/interactive-post-oklch-color-space...

[Brajeshwar]

OKLCH is widely supported in all modern browsers.[1] My easiest winning point with getting teams to start with OKLCH is that we can 'programmatically' control the color shades and tints by tinkering with numbers/values. To the designers (who don't write codes), I tell them that they can now focus on choosing the key colors (primary, accent, etc.) and then let CSS do the magic.

A good friend maintains a tool to tinker with various shades/tint of colors with OKLCH https://colorcolor.in

1. https://caniuse.com/?search=oklch

[block_dagger]

According to this article [1] OKLCH accounts for biases in human perception of color brightness. Seems useful, but I don't know the answer to your question.

[1] https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...

[CGamesPlay]

First, note that all colors in sRGB can be losslessly converted to OKLch (but not the other way around), so I don't know if this actually changes the colors or not.

The reason to use OKLch is so that when using CSS color mixing (via animations, gradients, etc), they look "better", as indicated by the sibling comments.

[bryanrasmussen]

OKLCH has the main advantage of LCH, which is that the numbers make sense, meaning that if you have two colors that are the same lightness they will look like they are the same lightness, because the numbers make sense you can now do programmatic color manipulation - increase lightness by 5 etc. that in the past would have been too difficult to really do (so people would instead just have variables giving the different rgb values and switch them in)

OKLCH just basically exists because there is a hue change from blue to purple in LCH when the lightness goes less which does not match how humans think of these colors (supposedly, don't know if there is any cultural difference)

So in OKLCH the lighter blue does not look purple like it does in LCH, it looks like lighter blue.

[CharlesW]

> Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here?

It's part of a wider adoption trend. https://bottosson.github.io/posts/oklab/#oklab-implementatio...

[dillonshook]

In case you're wondering how to pronounce it...

https://dillonshook.com/how-do-you-pronounce-oklch/

[chrismorgan]

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,<style>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));}</style><input type=color value=%23ff0000 onchange=document.body.style.setProperty("--from",this.value)><input type=color value=%230000ff onchange=document.body.style.setProperty("--to",this.value)><script>document.querySelectorAll("input").forEach(e=>e.onchange())</script><div style="--space:srgb">sRGB</div><div style="--space:oklab">Oklab</div><div style="--space:oklch">Oklch</div></body>

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.

[seanwilson]

Any thoughts on what color space you'd prefer to use? I'm working on a Tailwind palette creator (https://www.inclusivecolors.com/, it's based around letting you visualise the curves you mentioned), which uses HSLuv right now to avoid problem 2 in your list. HSLuv has perceptual uniformity as well (which is great at helping you pick colors that contrast) but it doesn't support P3 unfortunately, similar to Google's HCT color space.

I'm not seeing much demand for P3 at the moment though. Most designers I've spoke to don't know it exists.