Re: [csswg-drafts] [css-color-4] Channel clipping breaks author expectations, especially when using 'perceptually uniform' spaces (#9449)

I just opened a [PR](https://github.com/color-js/color.js/pull/438) on the @LeaVerou 's demo app with a variant on the algorithm, which does 2 things-

1. Returns immediately if the color is already in gamut, so it's a no-op
2. Handles Lightness = 0 and 1, converting to black and white, respectively.

You can see this on the deploy preview-
https://deploy-preview-438--colorjs.netlify.app/apps/gamut-mapping/?color=oklch(100%25+.8+250)

Some observations:
1. The transition to white and black is quick, whereas the CSS transition is more subtle (arrow up from L=90% to L+100% to see it transition). This may have some issues for gradients
2. Looking at  @tabatkins Step 6 [above](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1944235895), the second scale step seems to be necessary, even if the color is already gamut. I played around with it a bit, and it seemed like the results improved with a second scale.
3. I don't see a mathematical reason why it would be in gamut after the second scale, but I wasn't able to find any instances where it was out of gamut.
4. My observation is that the DeltaE's are often incredibly close between Scale LH and CSS, even when different channels are vastly different- see https://deploy-preview-438--colorjs.netlify.app/apps/gamut-mapping/?color=oklch(60%25+47%25+90)


-- 
GitHub Notification of comment by jamesnw
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1944265576 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 14 February 2024 17:16:02 UTC