| 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. [0]: https://oklch.com/ [1]: https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg... [2]: https://bottosson.github.io/posts/oklab/ |
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.
[0]: https://azan-n.pages.dev/projects/2023-06-08t061246138z/