If you asked me to pick out bright bold blue (#0000FF) and told me the format was "Lightness Chroma Hue" with valid ranges, I would guess "0.5 1.0 240". Not only is this "not visible on any monitor" by a very large margin but the oklch.com calculator states the spec fallback color is Dell logo blue and not bright at all while browsers will render "vibrant purple".

There's not "120 degrees of red, 120 degrees of green, 120 degrees of blue", so blue is not 240. Actual bright blue is hue 264. The "0-255 RGB" bright blue is 0.452 lightness, and max chroma on a really good monitor is something like 0.33. The lightness mostly makes sense, right? 0.5 is halfway between totally dark and completely washed out.

"Ok, so chroma tops at at 0.33" not so fast. You can crank up the chroma to 0.40 and still get either magenta (where lightness is around 0.74) or green (lightness around 0.78). So now you need to know a valid, nonlinear lightness range for each band of colors, because midpoint blue is different than midpoint red which is different from midpoint green.

From greyscale luminosity calculations and knowing about subpixels and bayer filters, I would've been able to guess that green is the color with the highest chroma, but then there's bright magenta, neck-and-neck. Oh. Until I move the lightness slider down on the web color picker, and then everything (especially peaks) in the chroma channel shifts around dramatically... So much for intuition.

While OKLCH makes it really convenient to select colors with properties you like along a gradient, the nonlinearity means either memorizing a bunch of base colors, using a color picker, or converting from a system that is "actually" intuitive. I can't really look at a trio of OKLCH numbers and predict the output color like I'd be able to with RGB, although this is mindful that RGB is also not linear (for the exact opposite reason as OKLCH) and I can only do that from decades of experience.

I'll concede that magenta and bright green and bold blue don't really have a place on the world wide web other than in a company logo, so these are outliers. Still, the OKLCH format is not what I'd call intuitive to a total beginner.

(Also, I'd very much not like to implement OKLCH calculations on a microcontroller until lighting companies start selling OKLCH LEDs.)

> So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.

What justification do you have to adopt and replace this with existing solutions with such urgency? Have you researched its compatibility? Are you providing any fallback?

This just seem to like 1) you are not applying your mind why you want this, 2) faulty premise that it makes it easier, because in reality your software never reaches a point of maturity, where its just "done", and 3) shiny object syndrome (https://en.wikipedia.org/wiki/Shiny_object_syndrome)

Standardization is valuable.

[dead]

OKLCH is as you say unambiguously better and IMO easier to understand than RGB, where choosing relative adaptations of colour is basically pretty fraught.

Alas, in terms of the software people use to mock up designs, very few desktop apps support it. HSL is, for now, the more practical option.

Perceptual colour spaces are emphatically not “simply better”. They’re better for most colour mixing (which is of more limited application than you may think) and for some sorts of intuitions, but their shape is far more complex, not mapping to the actual screen gamut in any predictable way, making them highly obnoxious for colour selection, because it’s super easy to fall out-of-gamut without realising it (and I don’t know of any tooling that draws your attention to when that happens) so that its entire purpose is compromised, and they’re downright atrocious at handling vivid (near edge-of-gamut) colours.

Take bright yellows as one of the worst examples. Basically the only thing you can do with them is reduce the chroma: any other change will take you out of gamut. As the most extreme case, #ff0 is approximately oklch(0.968 0.211 109.77), and the following minuscule modifications will take it out of gamut: L + 0.0002, L − 0.0001, C + 0.0002, H − 0.009 or H + 0.025.

This is why the creator massaged them into a cube/cylinder: https://bottosson.github.io/posts/colorpicker/, Okhsv and Okhsl. Those are much closer to being uniformly superior to sRGB.

Are RGB and HSL color models all broken and useless? Yes, I know their limitations. But of all graphical software I use daily. only GIMP supports LCh, and using it is pretty unintuitive.

I see how position-anchor and stuff are coll for complex layouts, but they have poor support on low-power mobile browsers, and, frankly, are not that useful for a minimalistic CSS framework. If you want complicated layouts with non-obvious anchoring rules, you're not the target audience.

Cascade layers are very useful for complex designs with many independently added stylesheets. They would be great to have. OTOH again, if you need this level of complexity, you're likely not the target audience of a pico-sized CSS framework.

I would say that a minimalist framework should make judicious use of CSS3 features, and not try to be excessively clever. In reliable engineering, being smart often means avoiding being clever.