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

@ccameron-chromium Pretty sure I've explained this to you before, but reading your comments here, the point seems to have been lost (but then again, you do have a track record of ignoring my comments, often even when I directly mention you…). So I’ll make another attempt.

Getting out of gamut, even out of Rec.2020, is not something that happens when authors do stupid sh*t, like you seem to be implying. It's something that happens **almost every time you try to use device independent polar spaces to accomplish their primary use cases**, such as creating tints and shades of a base accent color (lighter/darker variants).

Try it, please. Go [here](https://live-colors.verou.me/) and use your keyboard arrow keys to adjust the lightness and chroma of the colors at the top to create lighter/darker variations. If you get a red "P3+" circle, you're outside of Rec.2020 (an orange P3+ circle means outside P3 but inside Rec.2020).

Here's my attempt:

https://github.com/w3c/csswg-drafts/assets/175836/324c4165-ad64-44d2-b931-0adeb476313f

* Notice how much you need to reduce the chroma to even manage to stay in Rec.2020? 
* Notice how unpredictable the reduction is; how it varies _wildly_ based on what hue and lightness you're dealing with? 
* Notice how even if you get a chroma that gets you within P3 or sRGB, adjusting the lightness _just a little more_ (e.g. from 90% to 95%) gets you outside Rec.2020 again? Notice how sometimes even a single 1% increment will jump gamuts, with X% being in sRGB, (X+1)% in P3, (X+2)% in Rec.2020, and (X+3)% even outside that?

How on earth are authors supposed to do this for arbitrary dynamic accent colors stored in variables where they don't even *know* what they're dealing with? **OKLCH (and LCH) is useless without good gamut mapping**, not just from some sanctioned well-behaving gamut, but from any color.

This entire discussion, and the ones that preceded it, and the ones on Zoom, can be summarized in one sentence as "_Dozens of people who have done actual design work trying to explain to you why this is needed, and you repeatedly ignoring them._" Multiple people have tried to understand the constraints you folks are operating under and spent hours designing [gamut mapping algorithms](https://colorjs.io/apps/gamut-mapping/) that balance performance and quality in significantly better ways than clipping or the current CSS GMA. Not only did you not help this iterative process by elaborating on what the actual constraints are, **you did not as much as acknowledge their work**.

Call me a cynic, but I’m actually starting to wonder if there's actually _anything_ that would convince you to implement _any_ GMA, or if we're just all burning time and energy here until it becomes impossible to change the currently shipped behavior due to web compat.

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


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

Received on Wednesday, 6 March 2024 23:13:41 UTC