- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 16:59:41 +0000
- To: public-css-archive@w3.org
@ccameron-chromium > > you do have a track record of ignoring my comments > > I'm not sure if this is a productive remark. I would argue that repeatedly ignoring my comments is even less productive! This was an observation over several discussions and meetings, it wasn't just based on a couple data points. > 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. The same applies to me and many other commenters here. Our time is not inherently less valuable than yours, nor do we have fewer commitments. Which is exactly why I said that it's disrespectful that you are not only ignoring comments, but also the actual work by numerous people that has gone into solving this problem. Did you actually try the activity I suggested for making tints? It literally takes 2 minutes, and would be very illustrative. > 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. We are in agreement that the GMA in the spec needs improvement. **Yet you *still* have not acknowledged any of the work done by several people around improving the CSS GMA**, nor listed any implementation constraints these algorithms need to follow, so everyone is working in the dark. You even referred to the CSS GMA here and [have asked Google colleagues](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978970551) to evaluate it from a hardware perspective, yet radio silence on all the new GMAs that have emerged in the last few weeks. At this point it's pretty much certain that the CSS GMA will be replaced with one of them (or a variation), and it would be helpful to know what the constraints are to know which one that should be. E.g. edge-seeker by @ardov has performance comparable to clipping, but involves a LUT, so we need to know what size LUT is the limit for a GMA. Honestly, it would be far more productive to work together to figure out what a good CSS GMA should prioritize preserving and what the constraints are for designing a GMA that can be implemented in a GPU, rather than repeatedly arguing against GM and device independent color spaces as a concept. > * 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? Even if breaking this functionality were the only way, it's all about the balance of tradeoffs. It's a far more common use case to specify a color in CSS and expect to get a color that matches your intent, than to try and color match incorrect (clipped) colors between CSS and canvas! But breaking this is *not* the only way. I can think of at least 4 different solutions to this problem that don't sacrifice gamut mapping, but that should be discussed in a new issue that would be about actually solving the problem assuming that CSS GM exists, not about trying to get rid of gamut mapping. > * 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? Numerous people have responded to this argument that you keep making repeatedly. I will refrain from clogging this thread further by re-iterating their responses. > * 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? It's only alarming when you don't have good GM algorithms. > * 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? Again, this is a separate issue that should be discussed separately. No canvas-specific problem justifies crippling CSS color. > I think we can deliver the desired functionality without introducing these problems. I agree, but the path to that goes through GM. > > 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. FWIW I actually agree with this! Oklch is *not* the ideal space for this, it's just better than the others we have. I’ve spent some time studying color palettes generally regarded as aesthetically pleasing, and they’re actually *not* completely perceptually uniform (at least not by Oklch metrics). For example [here](https://live-colors.verou.me/open-colors/) is an analysis of [Open Color](https://yeun.github.io/open-color/) and I want to do the same with [Tailwind’s color palette](https://tailwindcss.com/docs/customizing-colors) which is also highly regarded. That said, GM will be needed for *any* color space. First, because not all screens have the same hardware, and second because any color space that is not designed around hardware will allow you to get OOG (yes, sometimes wildly). > > 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. Concepts like lightness, chroma, hue, have meaning regardless of which gamuts the color is in. We're only trying to preserve author intent here. > 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. RGB spaces are awful for creating dynamic variations, which is a pain point authors have had since forever. "Just specify your color in some RGB space" is not the answer. FWIW, I would be much more open to the idea of *only* having GM for device-independent spaces, exactly because the issue of preserving author intent is less prominent in RGB spaces. > 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. As I said above, GM will be needed for *any* color space. First, because not all screens have the same hardware, and second because any color space that is not designed around hardware will allow you to get OOG (yes, sometimes wildly). > The only argument I've heard against this approach is future-proofing concerns [such as](https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1225980544) "sRGB seemed plenty enough back in the 90s. Can we please not repeat the same mistake, just with P3 this time?". It generally tends to be a good thing to learn from past mistakes. > 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. Sigh. The only way you could specify colors that stay within these spaces is to use RGB, which as I explained above, is terrible for dynamic variations (and in general for human understanding). > For this reason, I think that we should provide content authors with a space that is perceptually uniform but does not suffer from this problem. A cylindrical space something like [okhsl](https://bottosson.github.io/posts/colorpicker/) would be nice. (That particular formulation is very tightly tied to the sRGB gamut, so it won't do as a verbatim drop-in). The CSS gamut mapping algorithm has the effect of cylinder-ifying the `oklab` and `oklch` spaces. OKHSL is *not* perceptually uniform, as @bottosson [said](https://bottosson.github.io/posts/colorpicker/) himself in the post defining OKHSL, e.g.: > This step makes the space less uniform perceptually, but is needed to fit the sRGB gamut to a cylinder exactly. It's just a space that has a better tradeoff of gamut fitting vs uniformity than both OKLCh and HSL which are on opposite ends of that spectrum. Also, the choice to restrict it to sRGB is a bit puzzling. It's not some distant future where sRGB is not sufficient, we're living it now. Only the lowest quality monitors today stay within sRGB. I have not checked with the other CSS Color editors, but I think it's highly unlikely that we'd add another sRGB-restricted space to CSS Color at this point. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1984007822 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 16:59:42 UTC