- From: Yi Xu via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 May 2023 03:59:07 +0000
- To: public-css-archive@w3.org
> > What I find odd about the CSS requirement is that it imposes a partial gamut correction, but only when lightness is 0 or 1, and before the final, displayable color is ready to be gamut mapped/clipped. I guess, my feeling is simply why bother correcting in these two scenarios, but nowhere else? > > I agree, the discontinuity (L=0 vs. L=0.01, etc) is not helpful and the desired result would occur because of gamut mapping to the display in any case. It seems that we agree that forcing the color to be black or white is not a desired user experience. Could we change the spec to reflect it? The current spec is as follows: > The first argument specifies the CIE Lightness, L. This is a number between 0% or 0 (representing black) and 100% or 100 (representing white), Values less than 0% or 0 must be clamped to 0% at parsed-value time; values greater than 100% or 100 are clamped to 100% at parsed-value time. Could we change to something like: > The first argument specifies the CIE Lightness, L. This is a number between 0% or 0 and 100% or 100, values less than 0% or 0 must be clamped to 0% at parsed-value time; values greater than 100% or 100 are clamped to 100% at parsed-value time. I found lab(100%, 0, 0)/lch(100%, 0, 0) maps to white and lab(0%, 0, 0)/lch(0%, 0, 0) maps to black is explained later in the spec: (https://drafts.csswg.org/css-color/#specifying-lab-lch) > If the lightness of a Lab color (after clamping) is 0%, or 100% both the a and b components are 0 and the color represents black, or white, respectively. -- GitHub Notification of comment by yiyix Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8794#issuecomment-1547156311 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 15 May 2023 03:59:09 UTC