Bug 255939 – (OK)LCH implementation is not according to spec

• Component: CSS
• Status: NEW

[Vasilis]

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.

[Radar WebKit Bug Importer]

<rdar://problem/108799783>

[Sebastian Zartner]

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

[Vasilis]

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.

[Vasilis]

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/

[Miriam Suzanne]

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.

[Karl Dubost]

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

[Philip Jägenstedt]

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.

[Matthieu Dubet]

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.

[Philip Jägenstedt]

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.

[Karl Dubost]

> If the lightness of a Lab color (after clamping) is 0%, or 100% the color will be displayed as black, or white, respectively due to gamut mapping to the display.

and

> If the chroma of an LCH color is 0%, the hue component is powerless. If the lightness of an LCH color (after clamping) is 0%, or 100%, the color will be displayed as black, or white, respectively due to gamut mapping to the display.
https://drafts.csswg.org/css-color-4/#specifying-lab-lch


> If the lightness of an Oklab color is 0% or 0, or 100% or 1.0, the color will be displayed as black, or white, respectively due to gamut mapping to the display.
https://drafts.csswg.org/css-color-4/#specifying-oklab-oklch

[Sam Weinig]

> If the lightness of an Oklab color is 0% or 0, or 100% or 1.0, the color will be displayed as black, or white, respectively due to gamut mapping to the display.

Its hard to understand how this could be true give gamut mapping is not currently defined/agreed upon. This seems more like wishful thinking for a future agreement on gamut mapping.

[Vasilis]

Is there any news on this bug? It’s such a pity that we still can’t use this. LCH promised us a way to create truly accessible colour palettes, where the colour contrast would always be the same, no matter the hue. The current implementation doesn’t do anything like this. It’s probably even worse than HSL at doing this.