261603 2023-09-15 06:34:11 -0700 Colors with lightness of 0 or 100 with a chroma that pushes the color out of gamut are displayed as non-white / non-black 2023-09-22 06:35:14 -0700 1 1 1 Unclassified WebKit CSS Safari 17 Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=261019 InRadar P2 Normal --- 1 romain webkit-unassigned heycam ntim webkit-bug-importer oldest_to_newest 1977672 0 romain 2023-09-15 06:34:11 -0700 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 1977683 1 ap 2023-09-15 08:21:26 -0700 Related to bug 261019 that was recently fixed, but still reproduces on ToT. 1977692 2 romain 2023-09-15 08:39:28 -0700 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. 1977693 3 romain 2023-09-15 08:40:25 -0700 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. 1979333 4 webkit-bug-importer 2023-09-22 06:35:14 -0700 <rdar://problem/115892202>