Bug 261603 – Colors with lightness of 0 or 100 with a chroma that pushes the color out of gamut are displayed as non-white / non-black

• Status: NEW
• Component: CSS

Example WPT tests :
- http://wpt.live/css/css-color/oklch-009.html
- https://github.com/web-platform-tests/wpt/blob/master/css/css-color/oklch-009.html

specification : https://drafts.csswg.org/css-color/#specifying-lab-lch

> 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.

WebKit doesn't current gamut map colors and instead clips.
This darkens colors that should actually be white/black.

https://codepen.io/romainmenke/pen/xxmLpRO

[Alexey Proskuryakov]

Related to bug 261019 that was recently fixed, but still reproduces on ToT.

I think this is a different issue.

The changes that were made for https://bugs.webkit.org/show_bug.cgi?id=261019 only apply to lightness values outside the relevant range.

This issue is about what happens with colors that have a lightness of 0 or "max" and that should be displayed as black or white.

When these colors also have some chroma/saturation they will be displayed as non-black/non-white.

This is most likely the result of converting to rgb or display-p3 and then clipping the channels.

To clarify.

> When these colors also have some chroma/saturation they will be displayed as non-black/non-white.

This is the current behavior and that behavior is incorrect.

They must be black/white.

[Radar WebKit Bug Importer]

<rdar://problem/115892202>