Bug 261603

Summary:	Colors with lightness of 0 or 100 with a chroma that pushes the color out of gamut are displayed as non-white / non-black
Product:	WebKit	Reporter:	romain
Component:	CSS	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	heycam, ntim, webkit-bug-importer
Priority:	P2	Keywords:	InRadar
Version:	Safari 17
Hardware:	Unspecified
OS:	Unspecified
See Also:	https://bugs.webkit.org/show_bug.cgi?id=261019

Description romain 2023-09-15 06:34:11 PDT

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

Comment 1 Alexey Proskuryakov 2023-09-15 08:21:26 PDT

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

Comment 2 romain 2023-09-15 08:39:28 PDT

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.

Comment 3 romain 2023-09-15 08:40:25 PDT

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.

Comment 4 Radar WebKit Bug Importer 2023-09-22 06:35:14 PDT

<rdar://problem/115892202>