OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown:
linear-gradient(in oklch, #f0f, #0f0)
You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow:
linear-gradient(in oklch longer hue, #f0f, #0f0)
The gradient shown (in either case) is a good example of a way that perceptual colour spaces are really bad to work in: practically the entire way round the edge of the circle, it’s outside sRGB, in fact way outside of the colours humans can perceive. Perceptual colour spaces are really bad at handling the edges of gamuts, where slightly perturbing the values take you out of gamut.
Accordingly, there are algorithms defined (yes, plural: not every application has agreed on the technique to use) to drag the colour back in-gamut, but it sacrifices the perceptual uniformity. The red in that gradient is way darker than the rest of it.
When you’re looking for better gradients, if you’re caring about perceptual uniformity (which frequently you shouldn’t, perceptual colour spaces are being massively overapplied), you should probably default to interpolating in Oklab instead, which takes a straight line from one side of the circle to the other—yes, through grey, if necessary.
linear-gradient(in oklab, #f0f, #0f0)
And in this case, that gets you about as decent a magenta-to-lime gradient as you can hope for, not going via red and yellow, and not exhibiting the inappropriate darkening of sRGB interpolation (… though if I were hand-tuning such a gradient, I’d actually go a bit darker than Oklab does).
During its beta period, Tailwind v4 tried shifting from sRGB to Oklch for gradient interpolation; by release, they’d decided Oklab was a safer default.
Also, isn't the way browsers interpolate colors in sRGB just a bug that I assume is retained for backwards compatibility? sRGB is a logarithmic encoding, you were never supposed to interpolate between colors directly in that encoding - the spec says you're suppose to convert to linear RGB first and do the interpolation there...
A good gradient is one that takes a perceptually uniform, and typically perceptually shortest, path. The OKLCH gradient isn't perceptual uniform and appears to take unnecessary detours through other hues.
Very interesting. Is this just a limitation of our current hardware? How much of this problem would still exist if everyone had a wider gamut monitor, say full DCI-P3? That still doesn't cover the full gamut of Oklch, but would it make the problem practically disappear?
No. We’re talking about colours way beyond the ranges of human perception.
For this specific gradient, see https://oklch.com/#0.7017,0.3225,328.36,100 and https://oklch.com/#0.86644,0.294827,142.4953,100, and look at the Chroma panel, see how far out of our screen gamuts they are (even tick “Show Rec2020”, which adds a lot of chroma around blue–green and magenta–red), and try to imagine the colours between the lime and magenta (in either direction). The red direction is probably the easier to reason about: there’s just no such colour as a light, bright red. You can have bright or light, but not both. (Its 3D view can also be useful to visualise these things: you’re building a straight-line bridge between two peaks, and there’s a chasm in between.)
But once an algorithm to drag the colours back in-gamut was applied, would the lost perceptual uniformity still be a problem practically speaking, with DCI-P3 monitors?
Yes. I repeat: these colours are way outside gamut. Not just a little bit. P3 helps a little bit, Rec.2020 would help a fair bit more, but you’re still asking for a yellow that is about twice as vibrant as is possible.
I don't get it, why am I seeing the "out of gamut" colors if my sRGB monitor is unable to display them? Would the charts look different on a P3 monitor?
edit: Also, you mentioned the colors "beyond the ranges of human perception" but I don't think there is any such limitation here, the bottleneck is the hardware (computer monitors).
The underlying problem is that the color space humans can see doesn’t have nice uniform linear boundaries. The larger your color space, the more relevant that issue actually becomes.
Also check out oklch.com, I found it useful for building an intuition. Some stumbling blocks are that hues aren’t the same as HSL hues, and max chroma is different depending on hue and lightness. This isn’t a bug, but a reflection of human eyes and computer screens; the alternative, as in HSL, is a consistent max but inconsistent meaning.
Another very cool thing about CSS’s OKLCH is it’s a formula, so you can write things like oklch(from var(--accent) calc(l + .1) c h). Do note, though, that you’ll need either some color theory or fiddling to figure out your formulas, my programmer’s intuition told me lies like “a shadow is just a lightness change, not a hue change”.
Also, OKLCH gradients aren’t objectively best, they’re consistently colorful. When used with similar hues, not like the article’s example, they can look very nice, but it’s not realistic; if your goal is how light mixes, then you actually want XYZ. More: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value....
Also, fun fact: the “ok” is actually just the word “ok”. The implication being that LCH was not OK, it had some bugs.
> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.
There is a very clear shift towards green in the OKLCH lightness value change example, enormously more so than any purple vibe in the HSL example.
Clearly being able to select colours of the same perceptual intensity has value, but some of the claims here as to the benefits are exaggerated.
The best axis for Lightness in my opinion is still the Gray-Scale (as used back in the day for black/white/grayscale TVs).
The newer CIE colorspaces (CIECAM02 CIECAM16) seem to address the effect, that color-perception goes wild if you change background and illumination. Oklab seems to only make some fixed choice about how to include the chromatic part to lightness. I'm not so sure, how this definition of lightness is any better than grayscale (from 1931).
Aside from a few criticisms that others have already raised I think this is quite a nice introduction to OKLCH and how to use them in CSS.
With that out of the way, I'd like to go on a tangent here: can anyone explain the modern trend of not including publishing dates in blog articles? It stood out to me here in particular because the opening sentence said that "OKLCH is a newer color model" and the "newer" part of that sentence will get dated quicker than you think. The main site does mention a date, but limits it to "August 2025" so this seems like a conscious choice and I just don't get it.
> can anyone explain the modern trend of not including publishing dates in blog articles?
In such cases, I usually try to see if the `Last-Modified` header served with the HTML document over HTTP, can be useful, but I conclude that often the same people who don't bother with dating their content -- you'd think they'd understand where the word _blog_ comes from, as in "[web]-log" where timestamps are paramount -- these same people don't know or care how HTTP works. Hint: the `Last-Modified` is the last modification time of the _resource_, in this case the actual HTML document. Just because your "backend" re-rendered the content because you didn't bother with setting up your server caching correctly, doesn't mean you should pretend it's a brand new content every day (which https://jakub.kr/components/oklch-colors does, unfortunately, so you won't know the timestamp from HTTP).
I would imagine this is rather to whatever "blog engine" is used instead of the conscious choice of the author (even if they knew what they desire and what would qork better, it might not be their priority).
I tried working with it but had to give it up for practical purposes. Whereas the focus with HSL is on the Lightness part and the Saturation is made to fit, OKHCL does it differently. It pushes the Chroma part to it's technical limits and abuses the Hue to make it fit, but we just do not understand Chroma intuitively.
I am waiting for OKHSL where the adjustments will bu much smaller and do not lead to absurd changes in intent.
I already had a discussion about it somewhere else (https://www.reddit.com/r/css/comments/1jv5f0r/hue_is_an_issu...)
On the comparison between Color spaces, it's weird, my monitor from 2008 does show a difference between the Display-P3 and the sRGB purple colors, yet I didn't think it'd have such a big color range. Is there some color conversion at the browser or OS-level? (my distro/desktop enables colormgr by default).
The first uses oklch(0.65 0.20 300), comfortably inside sRGB, not even at the boundary. The second uses oklch(0.65 0.28 300), which is well outside P3 and even Rec.2020.
The smallest fix would be to make the second one oklch(0.65 0.2399 300) to bring it inside P3 so the demo doesn’t get slightly warped if Rec.2020-capable (not really necessary, but preferable, I’d say), and the first #a95eff (oklch(0.6447 0.2297 301.67)) which is CSS’s fallback.
But purple is also pretty much the worst choice for such a demo—P3 adds the least to sRGB around there, so the difference will be smallest. A better choice is red or green.
So a better pair would be oklch(0.65 0.2977284 28) on the right (a bright red at the very edge of the P3 gamut, well outside sRGB) and #f00 on the left (the sRGB value CSS will map it to if out of gamut).
Sort of off topic questions, do we have any upcoming colour space beyond BT2020, now that we soon have monitor that reach 100% BT2020. I did some search and it doesn't seems to be any.
For any really bigger color space, you would have to use more than 3 primary colors, which would increase a lot the cost.
Moving the monochromatic BT.2020 colors from 630 nm, 532 nm and 467 nm could get a little increase in color space coverage, but at the expense of a lower efficiency in power consumption to brightness conversion. 467 nm is not a very pure blue, but the sensitivity of the eye drops very quickly in the blue region, so a better blue would require much more power. Similarly, though not so pronounced, for a different green.
Moreover, in the green region there is a gap, both for lasers and for LEDs, where the available devices have low efficiencies for converting electrical power to light, so changing the frequency of the primary green color would have to take that into account too.
In conclusion, I believe that the BT.2020 (actually BT.2100) color space is close to the best that can be done in displays of reasonable price and energy efficiency.
A true coverage of 100% of the BT.2100 color space can be realized only with laser projectors. Any display with LEDs or quantum dots will never have really monochromatic primary colors, though a coverage of significantly more than 90% of the BT.2100 color space is not too difficult. However, the advertised percentage of the color space may be misleading, because it varies depending on the kind of color space used for computations. A coverage percentage computed in OKlab would be more informative than a percentage computed in the XYZ color space.
While the above site is great for measuring with a modern contrast algorithm (it’s the current algorithm for the yet-to-be-released WCAG 3 accessibility standards), it’s worth bearing in mind that the WCAG 2 algorithm is somewhat different, and a legal requirement in many markets / industries. You can check your colours against that with a tool like https://www.siegemedia.com/contrast-ratio, although there are many more.
You can pick colors that pass both APCA and WCAG contrast checks though so it's not a problem to use APCA recommendations now.
I find APCA is a little stricter than WCAG for light themes, and APCA is much stricter than WCAG for dark themes, to the point where you really shouldn't use WCAG for dark themes. So most of the time APCA is giving you stricter contrast that easily pass WCAG also.
I keep seeing mentions that APCA will let you finally use e.g. white on orange, or white on vibrant blue that pass APCA but fail on WCAG, but my feeling is there's not a lot of examples like this and most of these pairings only have okay contrast anyway, not great contrast, so it's not ideal to be stuck with WCAG's false negatives but not that big of a deal.
If your colours have enough contrast to pass them both then of course that’s fine!
I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.
> I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.
Yeah I understand, would you agree this is fairly rare when using APCA though?
I've had the opposite where the brand guide was suggesting we use a light on dark combo that passed WCAG2, yet it failed APCA, and worst of all clearly had poor contrast just by looking at it. Yet, some people will still go with it because WCAG2 gave it the okay haha.
Maybe you've seen this but there's also https://github.com/Myndex/bridge-pca that does the "this color pair passes both APCA and WCAG2?" check in one pass.
As per discussion of this new OKLCH idea in TFA - Are we even sure we have great formulas for measuring/defining contrast in the first place? Do you agree / disagree with any of the counterexamples over at: https://github.com/tattoy-org/contrast-experiments
I'm not following. These examples are using the WCAG2 contrast algorithm which is well known to be flawed for people interested in this stuff, especially for dark themes so there should be lots of bad examples here? APCA is suppose to improve on this (see the example graphic comparing WCAG2 and APCA): https://git.apcacontrast.com/documentation/WhyAPCA.html
> But as @c-blake has rightly pointed out, this doesn't take into account the ratio of visible background pixels to foreground pixels. For example the contrast required for a single fullstop character, ".", is goting to be diffrent from a capital, "B".
So APCA includes more guidance on font weight and font size for more contexts (e.g. headings, body text, shorter text, copyright notices), but it's still going to be an approximation for edge cases like displaying a single fullstop character. If this case is common, you'd want to increase the contrast value instead of going with the minimum passing value, so the contrast algorithms can still help you.
There's a tradeoff with having guidelines that are very accurate (e.g. a contrast algorithm that counts pixels) vs simpler to follow (e.g. recommended font weight and size). People already find WCAG2 hard to follow as it is.
Does anyone know how this is different to the Munsell color space, which is also perceptually uniform?
Edit: I would imagine that the only way to definine a perceptually uniform color space is by tons of user testing. This is how Munsell developed his color space… specifically presenting test subjects with pairs of identical and near-identical color swatches and asking if they could tell the difference.
In this way, pairwise comparisom of similararity became the bedrock of color perception science.
Nice post. OKLCH is quite handy but for writing colors in CSS I hope eventually we’ll get some form of OKHSL/OKHSV[1] so users don’t need to worry about gamut boundaries.
That's quite misleading. The parent commenter was asking about gradient (interpolation between colors). Gradients look completely different in oklch and oklab.
Well yes, it's a different coorsinate system, so gradients would look different. It is still the same color space, but I agree I could have worded that better.
There is a youtuber (Gneiss Name) making educational content through the medium of Minecraft.
He's made one on OKLab as well: https://youtu.be/nJlZT5AE9zY
> It also works the other way around, where you can change the lightness value to create various color shades and there is no hue or saturation drift unlike in other color modes.
> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.
I see lots of automatic palette generator projects where the shades of each color are generated with OKLCH by only varying the lightness value on some chosen base color. The problem I find is if you look at popular open source palettes, the way the hand-crafted hue and saturation values vary across the shades for different hues isn't that predictable (the curve of the hue/saturation values over shades aren't straight lines or typical easing curves).
Hawking my own tool (using HSLuv with RGB for now), but you can load and compare the hue and saturation curves as they vary over shades of a color using example palettes from Tailwind 3, USWDS and IBM Carbon, plus tweak each shade to your liking:
So I think OKLCH is a nice starting base for palettes and a quick way to generate a color you need in CSS, but I think designers will always need to tweak the hue and saturation of each shade so it looks just right as there's no single right answer you could encode into the color space.
Hi Alexei, thanks for your work on HSLuv! I love the simplicity of it, where you can use HSLuv as mostly a drop-in replacement for HSL which most designers are familiar with.
I keep seeing new tutorials on designing accessible palettes that still use HSL, where the WCAG2 contrast breaks and goes all over the place as you vary the hue and saturation. HSLuv makes life so much easier here and lets you focus on exploring colors that you know will pass, using a familiar looking color picker.
colors are much more accurate in terms of
how humans perceive them and it makes
working with them much easier
This is an aim, which I am not sure fully addressed.
Think of the reason why can't I get oklch or any other method of color definition in HTML to produce the "gold color" as we humans think of it.
The fundamental reason you can't get a truly convincing "gold" color using a single value in oklch, rgb, or any other color definition is because gold is a material, not a color.
What our brain perceives as "gold" is not a single, flat hue.
It's a complex interplay of light, reflection, and texture.
Point is, even with sophisticated CSS involved with linear gradient it is still a challenge
These IP addresses being released at some point, and making their way into something else is probably the reason I never got to fully run my mailserver from my basement. These companies are just massively giving IP addresses a bad reputation, messing them up for any other use and then abandoning them. I wonder what this would look like when plotted: AI (and other toxic crawling) companies slowly consuming the IPv4 address space? Ideally we'd forced them into some corner of the IPv6 space I guess. I mean robots.txt seems not to be of any help here.
The “Better Gradients” thing is dodgy.
OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown:
You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow: The gradient shown (in either case) is a good example of a way that perceptual colour spaces are really bad to work in: practically the entire way round the edge of the circle, it’s outside sRGB, in fact way outside of the colours humans can perceive. Perceptual colour spaces are really bad at handling the edges of gamuts, where slightly perturbing the values take you out of gamut.Accordingly, there are algorithms defined (yes, plural: not every application has agreed on the technique to use) to drag the colour back in-gamut, but it sacrifices the perceptual uniformity. The red in that gradient is way darker than the rest of it.
When you’re looking for better gradients, if you’re caring about perceptual uniformity (which frequently you shouldn’t, perceptual colour spaces are being massively overapplied), you should probably default to interpolating in Oklab instead, which takes a straight line from one side of the circle to the other—yes, through grey, if necessary.
And in this case, that gets you about as decent a magenta-to-lime gradient as you can hope for, not going via red and yellow, and not exhibiting the inappropriate darkening of sRGB interpolation (… though if I were hand-tuning such a gradient, I’d actually go a bit darker than Oklab does).During its beta period, Tailwind v4 tried shifting from sRGB to Oklch for gradient interpolation; by release, they’d decided Oklab was a safer default.
Also, isn't the way browsers interpolate colors in sRGB just a bug that I assume is retained for backwards compatibility? sRGB is a logarithmic encoding, you were never supposed to interpolate between colors directly in that encoding - the spec says you're suppose to convert to linear RGB first and do the interpolation there...
This is super insightful, thank you! I wrote the article and will make changes to explain this better :)
For anyone else copy pasting the gradients into dev tools to look at them: The second one is missing the # sign on the first color.
And yes, both oklch gradients look pretty weird while the oklab gradient looks nice (if you can accept it going through grey).
Sorry, fixed.
But what really is a "color gradient"?
Isn't it any continuous function that starts at a specified color and ends at another specified color?
How then does one say that any gradient is good or bad?
Isn't the problem you are highlighting guaranteed to exist for any colorspace that defines colors outside of human perception?
A good gradient is one that takes a perceptually uniform, and typically perceptually shortest, path. The OKLCH gradient isn't perceptual uniform and appears to take unnecessary detours through other hues.
One could also argue that the detour through other hues is necessary in this case to avoid going through grey.
> The red in that gradient is way darker than the rest of it.
It doesn't look significantly darker to me.
Very interesting. Is this just a limitation of our current hardware? How much of this problem would still exist if everyone had a wider gamut monitor, say full DCI-P3? That still doesn't cover the full gamut of Oklch, but would it make the problem practically disappear?
No. We’re talking about colours way beyond the ranges of human perception.
For this specific gradient, see https://oklch.com/#0.7017,0.3225,328.36,100 and https://oklch.com/#0.86644,0.294827,142.4953,100, and look at the Chroma panel, see how far out of our screen gamuts they are (even tick “Show Rec2020”, which adds a lot of chroma around blue–green and magenta–red), and try to imagine the colours between the lime and magenta (in either direction). The red direction is probably the easier to reason about: there’s just no such colour as a light, bright red. You can have bright or light, but not both. (Its 3D view can also be useful to visualise these things: you’re building a straight-line bridge between two peaks, and there’s a chasm in between.)
But once an algorithm to drag the colours back in-gamut was applied, would the lost perceptual uniformity still be a problem practically speaking, with DCI-P3 monitors?
Yes. I repeat: these colours are way outside gamut. Not just a little bit. P3 helps a little bit, Rec.2020 would help a fair bit more, but you’re still asking for a yellow that is about twice as vibrant as is possible.
I don't get it, why am I seeing the "out of gamut" colors if my sRGB monitor is unable to display them? Would the charts look different on a P3 monitor?
edit: Also, you mentioned the colors "beyond the ranges of human perception" but I don't think there is any such limitation here, the bottleneck is the hardware (computer monitors).
It’s squashing the range of the colours down to simulate it.
The underlying problem is that the color space humans can see doesn’t have nice uniform linear boundaries. The larger your color space, the more relevant that issue actually becomes.
Great post!
Also check out oklch.com, I found it useful for building an intuition. Some stumbling blocks are that hues aren’t the same as HSL hues, and max chroma is different depending on hue and lightness. This isn’t a bug, but a reflection of human eyes and computer screens; the alternative, as in HSL, is a consistent max but inconsistent meaning.
Another very cool thing about CSS’s OKLCH is it’s a formula, so you can write things like oklch(from var(--accent) calc(l + .1) c h). Do note, though, that you’ll need either some color theory or fiddling to figure out your formulas, my programmer’s intuition told me lies like “a shadow is just a lightness change, not a hue change”.
Also, OKLCH gradients aren’t objectively best, they’re consistently colorful. When used with similar hues, not like the article’s example, they can look very nice, but it’s not realistic; if your goal is how light mixes, then you actually want XYZ. More: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value....
Also, fun fact: the “ok” is actually just the word “ok”. The implication being that LCH was not OK, it had some bugs.
> Another very cool thing about CSS’s OKLCH is it’s a formula
While it’s more useful for a perceptual color space, relative colors are supported for all CSS color spaces e.g.
> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.
There is a very clear shift towards green in the OKLCH lightness value change example, enormously more so than any purple vibe in the HSL example.
Clearly being able to select colours of the same perceptual intensity has value, but some of the claims here as to the benefits are exaggerated.
There’s no green shift at all in that example on my display. Could your calibration be off?
It's practically cyan, which is half way to green, not a lighter version of the blue to the left. This is on a MBP built in display.
This totally has uses but it is not, as claimed, "there is no hue or saturation drift" given the hue has shifted so much.
The best axis for Lightness in my opinion is still the Gray-Scale (as used back in the day for black/white/grayscale TVs).
The newer CIE colorspaces (CIECAM02 CIECAM16) seem to address the effect, that color-perception goes wild if you change background and illumination. Oklab seems to only make some fixed choice about how to include the chromatic part to lightness. I'm not so sure, how this definition of lightness is any better than grayscale (from 1931).
I found this to be a good article on the subject:
https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
Along with their picker / converter here:
https://oklch.com/
Discussed on Hacker News here:
https://news.ycombinator.com/item?id=43073819 (6 months ago, 30 comments)
Aside from a few criticisms that others have already raised I think this is quite a nice introduction to OKLCH and how to use them in CSS.
With that out of the way, I'd like to go on a tangent here: can anyone explain the modern trend of not including publishing dates in blog articles? It stood out to me here in particular because the opening sentence said that "OKLCH is a newer color model" and the "newer" part of that sentence will get dated quicker than you think. The main site does mention a date, but limits it to "August 2025" so this seems like a conscious choice and I just don't get it.
[0] https://jakub.kr/
> can anyone explain the modern trend of not including publishing dates in blog articles?
In such cases, I usually try to see if the `Last-Modified` header served with the HTML document over HTTP, can be useful, but I conclude that often the same people who don't bother with dating their content -- you'd think they'd understand where the word _blog_ comes from, as in "[web]-log" where timestamps are paramount -- these same people don't know or care how HTTP works. Hint: the `Last-Modified` is the last modification time of the _resource_, in this case the actual HTML document. Just because your "backend" re-rendered the content because you didn't bother with setting up your server caching correctly, doesn't mean you should pretend it's a brand new content every day (which https://jakub.kr/components/oklch-colors does, unfortunately, so you won't know the timestamp from HTTP).
I would imagine this is rather to whatever "blog engine" is used instead of the conscious choice of the author (even if they knew what they desire and what would qork better, it might not be their priority).
OKLCH: a color model based on OKLab (a perceptually uniform color space) where you control Lightness, Chroma (saturation), and Hue.
"OK" because "it does an ok job" according to its creater Björn Ottosson.
He’s Swedish, so I bet OK is actually short for “Ottossons kulör” but he’s just being modest.
In the spirit of "Oll Korrekt", "Otto's Kolors"?
How do you pronounce it, btw? "Oklich"? "okay L.C.H."?
Lich is an old word for a corpse (or in D&D mythology an undead magician).
An okay lich is like a chill corpse, maybe?
I tried working with it but had to give it up for practical purposes. Whereas the focus with HSL is on the Lightness part and the Saturation is made to fit, OKHCL does it differently. It pushes the Chroma part to it's technical limits and abuses the Hue to make it fit, but we just do not understand Chroma intuitively. I am waiting for OKHSL where the adjustments will bu much smaller and do not lead to absurd changes in intent. I already had a discussion about it somewhere else (https://www.reddit.com/r/css/comments/1jv5f0r/hue_is_an_issu...)
On the comparison between Color spaces, it's weird, my monitor from 2008 does show a difference between the Display-P3 and the sRGB purple colors, yet I didn't think it'd have such a big color range. Is there some color conversion at the browser or OS-level? (my distro/desktop enables colormgr by default).
It’s just completely wrong.
The first uses oklch(0.65 0.20 300), comfortably inside sRGB, not even at the boundary. The second uses oklch(0.65 0.28 300), which is well outside P3 and even Rec.2020.
The smallest fix would be to make the second one oklch(0.65 0.2399 300) to bring it inside P3 so the demo doesn’t get slightly warped if Rec.2020-capable (not really necessary, but preferable, I’d say), and the first #a95eff (oklch(0.6447 0.2297 301.67)) which is CSS’s fallback.
But purple is also pretty much the worst choice for such a demo—P3 adds the least to sRGB around there, so the difference will be smallest. A better choice is red or green.
So a better pair would be oklch(0.65 0.2977284 28) on the right (a bright red at the very edge of the P3 gamut, well outside sRGB) and #f00 on the left (the sRGB value CSS will map it to if out of gamut).
Sort of off topic questions, do we have any upcoming colour space beyond BT2020, now that we soon have monitor that reach 100% BT2020. I did some search and it doesn't seems to be any.
For any really bigger color space, you would have to use more than 3 primary colors, which would increase a lot the cost.
Moving the monochromatic BT.2020 colors from 630 nm, 532 nm and 467 nm could get a little increase in color space coverage, but at the expense of a lower efficiency in power consumption to brightness conversion. 467 nm is not a very pure blue, but the sensitivity of the eye drops very quickly in the blue region, so a better blue would require much more power. Similarly, though not so pronounced, for a different green.
Moreover, in the green region there is a gap, both for lasers and for LEDs, where the available devices have low efficiencies for converting electrical power to light, so changing the frequency of the primary green color would have to take that into account too.
In conclusion, I believe that the BT.2020 (actually BT.2100) color space is close to the best that can be done in displays of reasonable price and energy efficiency.
A true coverage of 100% of the BT.2100 color space can be realized only with laser projectors. Any display with LEDs or quantum dots will never have really monochromatic primary colors, though a coverage of significantly more than 90% of the BT.2100 color space is not too difficult. However, the advertised percentage of the color space may be misleading, because it varies depending on the kind of color space used for computations. A coverage percentage computed in OKlab would be more informative than a percentage computed in the XYZ color space.
Wherever you're working with colors and text/emblems, please also consider contrast and legibility: <https://apcacontrast.com/>
While the above site is great for measuring with a modern contrast algorithm (it’s the current algorithm for the yet-to-be-released WCAG 3 accessibility standards), it’s worth bearing in mind that the WCAG 2 algorithm is somewhat different, and a legal requirement in many markets / industries. You can check your colours against that with a tool like https://www.siegemedia.com/contrast-ratio, although there are many more.
Any reference to APCA has been removed from the WCAG 3 drafts in 2023 (see https://github.com/w3c/silver/commit/d5b364de1004d76caa7ddc4...).
I am not sure what the status is.
Oh, interesting, I’d missed that. Good info, thanks!
You can pick colors that pass both APCA and WCAG contrast checks though so it's not a problem to use APCA recommendations now.
I find APCA is a little stricter than WCAG for light themes, and APCA is much stricter than WCAG for dark themes, to the point where you really shouldn't use WCAG for dark themes. So most of the time APCA is giving you stricter contrast that easily pass WCAG also.
I keep seeing mentions that APCA will let you finally use e.g. white on orange, or white on vibrant blue that pass APCA but fail on WCAG, but my feeling is there's not a lot of examples like this and most of these pairings only have okay contrast anyway, not great contrast, so it's not ideal to be stuck with WCAG's false negatives but not that big of a deal.
If your colours have enough contrast to pass them both then of course that’s fine!
I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.
> I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.
Yeah I understand, would you agree this is fairly rare when using APCA though?
I've had the opposite where the brand guide was suggesting we use a light on dark combo that passed WCAG2, yet it failed APCA, and worst of all clearly had poor contrast just by looking at it. Yet, some people will still go with it because WCAG2 gave it the okay haha.
Rare, yes. Checking with both is definitely recommended!
Maybe you've seen this but there's also https://github.com/Myndex/bridge-pca that does the "this color pair passes both APCA and WCAG2?" check in one pass.
As per discussion of this new OKLCH idea in TFA - Are we even sure we have great formulas for measuring/defining contrast in the first place? Do you agree / disagree with any of the counterexamples over at: https://github.com/tattoy-org/contrast-experiments
I'm not following. These examples are using the WCAG2 contrast algorithm which is well known to be flawed for people interested in this stuff, especially for dark themes so there should be lots of bad examples here? APCA is suppose to improve on this (see the example graphic comparing WCAG2 and APCA): https://git.apcacontrast.com/documentation/WhyAPCA.html
> But as @c-blake has rightly pointed out, this doesn't take into account the ratio of visible background pixels to foreground pixels. For example the contrast required for a single fullstop character, ".", is goting to be diffrent from a capital, "B".
So APCA includes more guidance on font weight and font size for more contexts (e.g. headings, body text, shorter text, copyright notices), but it's still going to be an approximation for edge cases like displaying a single fullstop character. If this case is common, you'd want to increase the contrast value instead of going with the minimum passing value, so the contrast algorithms can still help you.
There's a tradeoff with having guidelines that are very accurate (e.g. a contrast algorithm that counts pixels) vs simpler to follow (e.g. recommended font weight and size). People already find WCAG2 hard to follow as it is.
My mind immediately translated OKLCH into "Oklachroma".
Does anyone know how this is different to the Munsell color space, which is also perceptually uniform?
Edit: I would imagine that the only way to definine a perceptually uniform color space is by tons of user testing. This is how Munsell developed his color space… specifically presenting test subjects with pairs of identical and near-identical color swatches and asking if they could tell the difference.
In this way, pairwise comparisom of similararity became the bedrock of color perception science.
My understanding is that it's the same with higher resolution.
Nice post. OKLCH is quite handy but for writing colors in CSS I hope eventually we’ll get some form of OKHSL/OKHSV[1] so users don’t need to worry about gamut boundaries.
[1] https://bottosson.github.io/posts/colorpicker/
I've not touched oklch, but I've played with oklab gradients a fair amount.
How do they (oklch & oklab) compare for different uses?
oklch uses the oklab color space.
The oklch color space is polar: it’s a cylindrical transformation of the oklab cartesian color space.
That's quite misleading. The parent commenter was asking about gradient (interpolation between colors). Gradients look completely different in oklch and oklab.
Well yes, it's a different coorsinate system, so gradients would look different. It is still the same color space, but I agree I could have worded that better.
Creator of OKLCH on OKLCH:
https://bottosson.github.io/posts/oklab/
There is a youtuber (Gneiss Name) making educational content through the medium of Minecraft. He's made one on OKLab as well: https://youtu.be/nJlZT5AE9zY
How does oklch compare to CIELCh(uv)? I've been using that seemingly similar system to pick uniform colors.
Seems nice. But how to pronounce it?
That's one reason to prefer Oklab ;)
With great difficulty.
Like "okay lock" I would guess.
o k l c h
"Oh, clutch"?
Thanks for this post. Hackernews is sometimes awesome for learning opportunities like this. Never heard of the model, thankful for the article.
> It also works the other way around, where you can change the lightness value to create various color shades and there is no hue or saturation drift unlike in other color modes.
> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.
I see lots of automatic palette generator projects where the shades of each color are generated with OKLCH by only varying the lightness value on some chosen base color. The problem I find is if you look at popular open source palettes, the way the hand-crafted hue and saturation values vary across the shades for different hues isn't that predictable (the curve of the hue/saturation values over shades aren't straight lines or typical easing curves).
Hawking my own tool (using HSLuv with RGB for now), but you can load and compare the hue and saturation curves as they vary over shades of a color using example palettes from Tailwind 3, USWDS and IBM Carbon, plus tweak each shade to your liking:
https://www.inclusivecolors.com/?style_dictionary=eyJjb2xvci...
So I think OKLCH is a nice starting base for palettes and a quick way to generate a color you need in CSS, but I think designers will always need to tweak the hue and saturation of each shade so it looks just right as there's no single right answer you could encode into the color space.
Wow, this might be the best use of HSLuv so far, I'm going to add it to the examples page https://www.hsluv.org/examples/
Hi Alexei, thanks for your work on HSLuv! I love the simplicity of it, where you can use HSLuv as mostly a drop-in replacement for HSL which most designers are familiar with.
I keep seeing new tutorials on designing accessible palettes that still use HSL, where the WCAG2 contrast breaks and goes all over the place as you vary the hue and saturation. HSLuv makes life so much easier here and lets you focus on exploring colors that you know will pass, using a familiar looking color picker.
In the chromaticity diagram, is my Display-P3 screen mapping everything outside the triangle back into the triangle?
Yes, the diagram is a representation. Kind off like drawing 3D shapes on a 2D surface.
Quote:
This is an aim, which I am not sure fully addressed. Think of the reason why can't I get oklch or any other method of color definition in HTML to produce the "gold color" as we humans think of it.The fundamental reason you can't get a truly convincing "gold" color using a single value in oklch, rgb, or any other color definition is because gold is a material, not a color.
What our brain perceives as "gold" is not a single, flat hue. It's a complex interplay of light, reflection, and texture.
Point is, even with sophisticated CSS involved with linear gradient it is still a challenge
See demo at https://jsfiddle.net/oyw9fjda/
---
That gradient example is hilarious.
With RGB you order green salad you get green salad.
With OKLCH you order green salad you get beet soup.
Really happy about oklch. You do have to learn the hue numbers, but once you do, everything is more intuitive.
I was wondering about this exact subject the other day when working on some web dev task. Now I know why this way is better.
seems like a great idea, this will make working with colors so much easier
Awesome Post
These IP addresses being released at some point, and making their way into something else is probably the reason I never got to fully run my mailserver from my basement. These companies are just massively giving IP addresses a bad reputation, messing them up for any other use and then abandoning them. I wonder what this would look like when plotted: AI (and other toxic crawling) companies slowly consuming the IPv4 address space? Ideally we'd forced them into some corner of the IPv6 space I guess. I mean robots.txt seems not to be of any help here.
I think you commented on the wrong post :)
Oops,haha, you're right! Should have been https://news.ycombinator.com/item?id=45010183
Apologies! (I can't delete the post though, feel free to down-vote into oblivion)