For example, the page background and the text color can be adapted to match colors from a photo.
I am using oklch for the automatic choice of the background color on ClickHouse SQL UI: https://play.clickhouse.com/ - when you run a query, the background automatically adapts for it.
Imagine a design team and web development team both at the top of their game, ensuring perfect color matching to their manufactured product and trademarked logo using state-of-the-art tooling and technologies, including those in the linked post. I'd be surprised if a single consumer monitor correctly match the color on the website those teams created.
Even further, I suspect most web designers don't even use calibrated monitors.
Maybe this would be useful for a design-centric service website?
And even if your users may not use color calibrated monitors, you’re still better off picking the correct color on a calibrated monitor rather than doubling up on the error.
Also, none of this is new. Even if you used #aabbcc color codes, you were implicitly choosing the sRGB colorspace even if you had no idea about colorspaces. There isn’t a solution that gets rid of colorspaces… it’s like suggesting that it’s possible to specify length without a unit like meters or inches. The colorspace is the unit.
Rounded to the nearest percent, 0% of users have calibration tools, nor are they running their monitor in a meaningfully calibrated state from the factory. It's all running at higher brightness and saturation because that's what users think looks better.
If most users are running super-saturated and super-bright, and color matching to what those users are seeing is important, it would be better to use that as the baseline instead of a calibrated monitor.
Of course, human vision is quite sophisticated at adapting to various conditions, so the colors will not be precisely perceptually matching unless the observations take place in a standard setting. If one observer is sitting under a fluorescent bulb, another is in a dark room, and a third is sitting outside on a sunny day, all bets are off. There's also nontrivial inter-observer variation, even among people with normal color vision.
I don't know about you, but I am much better at decoding separate RGB values (as in, including hex) than I am at decoding a single chroma value. What am I supposed to do with a chroma value, try to imagine a chart to place it on? Memorize the values of each color on the spectrum? I'm not saying it's unreasonable to expect somebody to be able to learn this, but in my opinion it's not very fair to say LCH is somehow automatically more readable than RGB.
I can do it, but RGB and HEX are awful for me. A lot of mental work must be done to get to decimal/hex colors:
1. Memorize what happens when you mix combinations of RGB.
2. Learn/internalize hex
3. Mentally map how each color might roughly look in both decimal and hex.
All of that can be learned of course, but that's a lot of work compared to memorizing four numeric waypoints for hues (Red, Yellow, Blue, Green) to start. The rest was super easy for me once I knew that Chroma is how much color you're putting in (0=gray). By the way, you mentioned Chroma earlier. Did you mean Hue instead?
The beauty of OKLCH is that you don't absolutely have to know Hue cold to work with colors and create variations. You can pick your primary, secondary, etc. colors. Then set the Chroma (which probably remains the same throughout your palette) and Hue to CSS variables. Then forget about their real values and just use the variables. To get a color palette, adjust with the brightness to develop as many levels of a color as needed. Then, take that color and copy/paste for however many colors you have in your palette, replacing the hue with a different variable for each color. All the colors will have the same perceived brightness at a given level of lightness, which is a huge win that isn't easily achieved in other color systems like RGB.
oops yes I meant hue sorry. I was probably thinking of the chrominance video signal lmao
List doesn't include "the same color should look the same on all renderers/browsers". One of the problems with CYMK (intended for print, not screen) is that screens render in RGB and each browser has it's own algorithm for how to convert from CYMK to RGB. So if you have an image in CYMK and use that on the web, it looks different on different browsers. And people complain and then you need to explain to them "convert it to RGB and use that, because this isn't a problem with the site it's a problem with the encoding not being meant for the site".
No browser supports CMYK, and using an RGB color space (browsers in popular use support two) doesn't solve this problem, even setting aside that some browsers support color management by default and some don't.
I'm not sure what you mean by this. Every browser supports CMYK color encoding/space; they just transform it into RGB on the fly.
You have an unusual definition of "support". You can't specify colors in CMYK, there's no such thing as a CMYK <canvas>, etc.
Sure, you may get a rectangle with an image when you view a CMYK JPEG, but that's an unintended, virtually untested consequence of the bundled or OS media decoder associated with the file type.
For a general purpose, the results will just be bad, and anyone putting such images on the web is doing it wrong.
Oklab / Oklch is a different topic than the display of bitmap images, so if CMYK JPEGs is what you had in mind it's a bit of a tangent.
My only complaint for usability has nothing to do with oklch but at the time of writing it does not appear that vscode displays the colorblocks or selector for oklch, which just adds another tiny bit of a painpoint for me.
Either way, going to be using it in my current side project!
See the part on https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg... and notice the cut out in the right column. Now pretend to stretch those cutouts to fit the edges of the chart, you'll have a color gradient that is more uniform across the board versus the left where you have darker areas.
They sold HSL to us as a way to vary the hue easily in a way that's not possible with #000000 without manually computing it first. The reality is that the hue parameter in HSL also considerably changes the luminosity of the color.
The tool you linked only demonstrates that OKLCH can also display colors that rgb() can't, but most of them are the same.
if im doing color-anything, i do enjoy manipulating the raw colors over any integer representation of them, then sending whatever code i need back to whatever.
im more irk'd at the main linked page, shows up nice and dark background, then scroll down a hair and its back to staring at the day-star, ie white background and eye killer. why oh why? ha, if i scroll up and down fast enough its like a strobe light. weeeee. and there was another HN page related to oklch themes yesterday that did the same thing; making me improperly biased already.
please folks, dont make a mess of my dark mode