I really love that the color picker site (https://oklch.evilmartians.io/) supports P3 and Rec2020. I’m excited that we can finally start breaking the chains of sRGB on the web!
I personally don’t find it very easy to translate the values of any system (OKLCH, HSL, or RGB) into a color in my head. I might be able to guess what a color might look like based on a ROYGBIV color wheel and a degree value, but in practice I find it difficult to account for the fact that 0/360º on the circle is halfway between red and violet, so whereas I would expect 180º to be a pure green, it’s more of a turquoise.
What I do appreciate, however, is being able to take a known color and make some variant of it with predictable results that are more in line with human perception than raw RGB channel amplitudes. I have had the exact same frustrations with SCSS’ darken() as described in the article; it never looks right.
Whereas with this new standard, I can do the same thing natively and have it come out looking right. If I have, for example, this known blue:
…by tweaking just one value. I can do the same with chroma, which I find more valuable when implementing color palettes than saturation.
What I find confusing is what happens when some combination of values go outside the color space. When this color picker says something is unavailable on any device and renders a “fallback,” is that what the native browser implementation will do, too? Is there any reason not to use a value for which some fallback must be substituted?
For an ELI5, here’s the minutephysics YouTube video for why the darken() functions in Sass and Less are broken and also CSS’s native blur(): Computer Color is Broken
Whereas with this new standard, I can do the same thing natively and have it come out looking right.
And this is exactly the “human readable” part of the new color scheme. With this you can mathematically change the colors and have something get out that looks as expected, especially with regard the lightness and when having two contrasting colors (foreground and background).
Previously this was somewhat possible by using HSL, however you always had to visually check that the new saturation or lightness works as expected in the proper context.
There are links to the W3C Color Module Level 4 candidate recommendation, which includes algorithms for conversion, and the source code to Evil Martians’ implementations in the tools they built in their article. Bear in mind that most digital color spaces have a smaller gamut than OKLCH or OKLAB, so information will be lost in the conversion.
I really love that the color picker site (https://oklch.evilmartians.io/) supports P3 and Rec2020. I’m excited that we can finally start breaking the chains of sRGB on the web!
Could someone explain this? I’m not sure I understand how this works, how do I know that oklch(45% 0.26 264) is blue?
You don’t. Well, you do if you know that .26 points at blue, but that’s not a safe assumption.
I personally don’t find it very easy to translate the values of any system (OKLCH, HSL, or RGB) into a color in my head. I might be able to guess what a color might look like based on a ROYGBIV color wheel and a degree value, but in practice I find it difficult to account for the fact that 0/360º on the circle is halfway between red and violet, so whereas I would expect 180º to be a pure green, it’s more of a turquoise.
What I do appreciate, however, is being able to take a known color and make some variant of it with predictable results that are more in line with human perception than raw RGB channel amplitudes. I have had the exact same frustrations with SCSS’
darken()as described in the article; it never looks right.Whereas with this new standard, I can do the same thing natively and have it come out looking right. If I have, for example, this known blue:
https://oklch.evilmartians.io/#45,0.26,264,100
I can theoretically make a lighter:
https://oklch.evilmartians.io/#75,0.26,264,100
or darker version:
https://oklch.evilmartians.io/#25,0.26,264,100
…by tweaking just one value. I can do the same with chroma, which I find more valuable when implementing color palettes than saturation.
What I find confusing is what happens when some combination of values go outside the color space. When this color picker says something is unavailable on any device and renders a “fallback,” is that what the native browser implementation will do, too? Is there any reason not to use a value for which some fallback must be substituted?
For an ELI5, here’s the minutephysics YouTube video for why the
darken()functions in Sass and Less are broken and also CSS’s nativeblur(): Computer Color is BrokenAnd this is exactly the “human readable” part of the new color scheme. With this you can mathematically change the colors and have something get out that looks as expected, especially with regard the lightness and when having two contrasting colors (foreground and background).
Previously this was somewhat possible by using HSL, however you always had to visually check that the new saturation or lightness works as expected in the proper context.
Is there a description of the algorithm for converting OKLCH to other color formats, so one can implement a converter?
There are links to the W3C Color Module Level 4 candidate recommendation, which includes algorithms for conversion, and the source code to Evil Martians’ implementations in the tools they built in their article. Bear in mind that most digital color spaces have a smaller gamut than OKLCH or OKLAB, so information will be lost in the conversion.