The implementation of LCH and OKLCH is incorrect. According to the spec `oklch(1 0.4 240)` should be white, and `oklch(0 0.4 240)` should be black: > "If the lightness of an Oklch color is 0% or 0, or 100% or 1.0, the hue component is powerless and the chroma is 0." https://drafts.csswg.org/css-color-4/#specifying-oklab-oklch Here’s a test URL: https://vasilis.nl/dingen/bugs/oklch.html You can see that all four squares are not black nor white. This is of course a bug. Plain LCH should behave the same of course and as you can see it is buggy in the same way.
<rdar://problem/108799783>
The following web platform tests are affected by this bug: https://wpt.fyi/results/css/css-color/lch-009.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/css-color/lch-l-over-100-1.html?label=experimental&label=master&aligned * https://wpt.fyi/results/css/css-color/oklch-009.html?label=experimental&label=master&aligned https://wpt.fyi/results/css/css-color/oklch-010.html?label=experimental&label=master&aligned * Also requires clamping the luminance value to 100 as required by the spec. > Values less than 0% or 0.0 must be clamped to 0% at parsed-value time; values greater than 100% or 1.0 are clamped to 100% at parsed-value time. Sebastian
I’m not sure how the prioritization of bugs works exactly, but I think this should have a higher priority: once this bug is fixed, websites that use (ok)lch will look different, in some cases even completely different. They may turn unusable depending on the use. Bright colors may turn white, and subtle dark colors may turn completely black. All colors will probably change. Some a bit, others dramatically. The more websites use this color function the bigger the problem will be. It should be fixed.
There’s a javascript implementation of LCH that seems to be accurate. I’m not sure if it’s 100% accurate, but looking at the authors it could very well be. Maybe that helps? https://css.land/lch/
Authors have been very excited about this feature, as a way to achieve more perceptually-uniform lightness. That was sold to us as the entire reason for this color format in the first place. It seems pretty shocking that all browsers shipped the format in a way that is not even close to perceptually uniform. This is not a small bug - it fundamentally breaks the entire purpose of the color format.
Created attachment 469827 [details] rendering in safari, firefox, chrome rendering of https://vasilis.nl/dingen/bugs/oklch.html Safari Technology Preview 188 19619.1.2.1.1 Firefox Nightly 124.0a1 12424.2.9 Google Chrome Canary 123.0.6290.0 6290.0
Note that implementing this as a special case for 0 and 100 in Chrome has resulting in an unfortunate discontinuity when moving a tiny distance away from 0 or 100. I've filed https://issues.chromium.org/issues/329106317. It would be good to coordinate a bit to resolve the interoperability issue we now have, while also shipping behavior that is reasonable for developers.
Indeed, this special case for lightness being <= 0 or >= 100 give some surprising discontinuity. There are ongoing discussions in the CSS working group around gamut mapping like https://github.com/w3c/csswg-drafts/issues/9449 which would certainly change this behaviour. Implementing this change in the meantime might be counter productive from a browser compatibility point of view.
I agree that making changes right now is a bit risky because discussions are still very active. In the meantime I've sent https://github.com/web-platform-tests/wpt/pull/45073 to guard against the discontinuity between 99.9999% and 100% lightness.