- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 13:32:17 +0000
- To: public-css-archive@w3.org
> you do have a track record of ignoring my comments I'm not sure if this is a productive remark. It takes a lot of time and effort for me to follow and contribute to this thread, and I have to balance it with other commitments. > 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." I hope I'm not giving the impression that I'm ignoring the desire for this functionality. I've been trying to give the feedback that the spec has problems in the way it tries to deliver this functionality. When one works out all of the implications of the spec, complexity spirals and things start breaking. Some of the issues I've been bringing up are: * This [breaks](https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1216700728) the ability to color match between CSS colors and images. Why is it okay to break this functionality? Is there a way that we can avoid breaking this? * Mapping to the target display is future-dangerous instead of future-proof, because colors will radically change as display capability evolves. A page that shows the top bar in [this image](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1980976323) should slowly converge to the bottom bar as monitors become more capable. Is there a solution that avoids this problem? * It's alarming that users are encouraged to specify physically-non-existent colors and expect specific behaviors from them. Likewise for far-out-of-gamut colors. Can this be avoided? * An ambiguity that still remains is what to do when rendering to an offscreen `CanvasRenderingContext2D`. To what gamut should we map? The target display is unknowable as it may go to any of many monitors on the system, or none. How should this interact with adding floating-point canvas? Is there a solution that avoids these ambiguities? I think we can deliver the desired functionality without introducing these problems. > OKLCH (and LCH) is useless without good gamut mapping I agree. The spec is trying to use those spaces to do something that they are not designed for. They are not spaces where one can adjust the L parameter of a given color from 0% to 100% and get reasonable results. The result is far-out-of-gamut and physically-impossible colors. If we want a space that has that can be used that way, we need to define one. It is not `oklch` as currently defined. > but I’m actually starting to wonder if there's actually anything that would convince you to implement any GMA What we're trying to do with gamut mapping is to make `oklch` be something that it isn't. It makes the far-out-of-gamut and physically-impossible colors of `oklch` behave in a way counter to their physical meaning, and imposes that transformation on all other colors. As one pulls on this thread, things fall apart. The solution I've been arguing for [above](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1981703947) and at the F2F is to provide safe color spaces that can be used in this way without going too far out of a specified gamut (say, sRGB, P3, or Rec2020). We can do this by adding new spaces, or modifying existing ones. Such an approach provides the desired functionality without introducing the above-mentioned problems. It does not require a gamut mapping algorithm except perhaps within the definition of individual spaces. The only argument I've heard against this approach is future-proofing concerns such as ["sRGB seemed plenty enough back in the 90s. Can we please not repeat the same mistake, just with P3 this time?"](https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1225980544). Having options that target sRGB, P3, and Rec2020 should be plenty for now, and we can very easily add more options as need arises. In contrast, the use-far-out-colors-then-gamut-map-to-the-display approach is unavoidably future-dangerous. The goal of the spec is good and we should work towards it, it the approach it is taking has problems that need to be addressed. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1983516454 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 March 2024 13:32:19 UTC