This article mentions a notable limitation of the HSL colour model:
> Perceived brightness is not at all uniform at equal starting points, it depends on the hue, as well as the saturation.
…but it doesn't mention an (under-discussed) solution available: using a better colour model. OKLCH uses similarly understandable coordinates, "chroma" being roughly the same concept as "saturation", but is designed to avoid just this kind of problem. That is, if you change the "hue" coordinate, you can reasonably expect the perceived lightness and chroma of the resulting colour not to change. Where such a colour does not exist, e.g. a blue with the same lightness and chroma as #FFFF00 yellow, it's simply out of gamut.
There's a colour picker web app[0] that shows the boundaries of the space along with smaller spaces like sRGB, and it's helpful for getting a feel for it. It also links to a post[1] laying out the reasons to use OKLCH in web projects (it's now supported by all three major engines), and the post[2] introducing OKLAB (same space, different coordinate system) is heavy on technical details.
Thank you for sharing. I've published a small case-study[0] working with OKLCH with Angular Material which is a large UI library for the Angular framework.
Edit: What I find particulary difficult with OKLCH is sharing it across projects (think Android, iOS, and Web). I have tried figuring out solutions in Style Dictionary where I could generate colors and manually convert them to Hex or HSL for other platforms but the solution needs a fair amount of complexity that I am not willing to work with.
This is great. I keep making attempts trying to understand CIELAB and similar, with perceived brightness as my main concern. OKLAB looks like it’s exactly what I need.
oklch.com is an absolutely fantastic resource, thank you for sharing it.
I was able to see how limited our devices are when it comes to high chroma colors and I was only able to select purple. We are fooling ourselves and our users if we keep using HSL and think it’s acceptable.
Nice that it tells you that some colour is not available in your current gamut but it is in e.g P3... which reminded me that my monitor is P3-able but I forgot to set the proper profile!
> Perceived brightness is not at all uniform at equal starting points, it depends on the hue, as well as the saturation.
…but it doesn't mention an (under-discussed) solution available: using a better colour model. OKLCH uses similarly understandable coordinates, "chroma" being roughly the same concept as "saturation", but is designed to avoid just this kind of problem. That is, if you change the "hue" coordinate, you can reasonably expect the perceived lightness and chroma of the resulting colour not to change. Where such a colour does not exist, e.g. a blue with the same lightness and chroma as #FFFF00 yellow, it's simply out of gamut.
There's a colour picker web app[0] that shows the boundaries of the space along with smaller spaces like sRGB, and it's helpful for getting a feel for it. It also links to a post[1] laying out the reasons to use OKLCH in web projects (it's now supported by all three major engines), and the post[2] introducing OKLAB (same space, different coordinate system) is heavy on technical details.
[0]: https://oklch.com/
[1]: https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
[2]: https://bottosson.github.io/posts/oklab/