This is not an issue in the css-color-4 spec, but in all the implementations. While issues have been filed on the individual bug trackers, I wanted to raise the issue with the CSSWG since it seems like this was an intentional decision agreed to by the browser vendors.

Here are the individual bug reports:

• https://bugs.webkit.org/show_bug.cgi?id=255939
• https://bugzilla.mozilla.org/show_bug.cgi?id=1847421
• https://bugs.chromium.org/p/chromium/issues/detail?id=1440069&q=lch&can=2

And, as I understand, the decision was made in these CSSWG issues:

• [css-color-4] Disagreements over gamut mapping #7610
• [css-color-4] CSS gamut mapping algorithm clarifications #7653

I'm opening a separate issue because I don't have strong feelings about all the details of a gamut mapping algorithm, but I'm pretty frustrated about the state of what browsers shipped here, and I think we need to do something to fix it asap. From an authoring perspective it's entirely unusable, and it breaks the fundamental promise of the format: providing perceptually-uniform lightness.

• Here's a codepen demo showing two colors with the same hue and lightness values, but vastly different perceptual lightness in the results.
• Here's a tool for comparing gamut-mapping options - set the lightness low (eg 0.25) and clip gives colors which are over-saturated/too light, set the lightness high (eg .85) and clip gives over-saturated and too dark.

This is the format that authors were most excited about, and it doesn't do what we told them it does. I really wish this feature hadn't shipped at all, since it clearly wasn't ready to ship. Adding agenda+ because I think this deserves more eyes on it, and more urgency in fixing it.