- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Dec 2020 17:57:08 +0000
- To: public-css-archive@w3.org
@argyleink > Lab / perceptual color spaces have been around since the 70's, have terrible adoption in tooling (designer and developer tooling) Lab/LCH have poor adoption for user-facing stuff, but are used internally for a number of algorithms. We've already discussed why web-facing stuff doesn't use them. > From what I can tell, we all agree on: > - when/if lab/lch are available in the browser, use it for the color functions not sRGB > What we disagree on: > - blocking color functions with lab/lch color space support **There is no blocking**: Engineers are free to implement these functions with an explicit `srgb` specifier, since they allow for color space specification. We just don't want to make gamma-corrected sRGB **the default**, because it's an awful space for manipulation. Here's an example of why: https://colorjs.io/notebook/?storage=https%3A%2F%2Fgist.github.com%2FLeaVerou%2Fd2894bb1281164c325e1bb40b12f1437  And here is a lovely video explainer: https://www.youtube.com/watch?v=LKnqECcg6Gw Once we define `lighten()` and `darken()` and the other shortcuts as using HSL/sRGB by default, we're stuck with that forever. Same with `color-mix()` and the like. We can never change the meaning of existing syntax, you know that by now. Therefore, I would strongly object to defining convenience functions that produce poor results just to get a quick fix in. That is not a good way to evolve the Web Platform. We can do better. One thing to communicate to your engineers is that perhaps they don't actually need to implement Lab/LCH color values to do simple color manipulation in these spaces. [The math is actually pretty simple](https://www.w3.org/TR/css-color-4/#color-conversion-code), and they can just implement that directly until they're ready to properly implement Lab/LCH. One downside if they take that route and output sRGB as the result is there will be pointless gamut clipping for colors outside sRGB but within the screen gamut. They could get around to that by implementing `color(display-p3)` like Safari did, and outputting values in that. In any case, it would be good to invite said engineers either in this issue or another one to express their implementation concerns so @svgeesus and I could talk to them directly, as this game of broken telephone does not facilitate communication. We have both seen a lot of such concerns that upon closer investigation turned out to be unfounded, so I think it could be a very productive discussion. > From what I can tell, we all agree on: > - middle ground complexity functions `color-adjust(black lightness -20%)` > - advanced destructuring and relative functions `hsl(from black h s calc(l - 20%))` I don't think these are things we all agree on, since I proposed removing both of these in an earlier comment. What I've seen in the data is huge, huge usage of simple manipulations (darken, lighten, opacity, mix) and then math on individual components for more complex manipulations. Middle ground complexity seems to serve very few use cases to be worth it; is too complex for the simple cases and not powerful enough for the complicated ones. For similar reasons, I'm not in favor of my own relative syntax proposal anymore. It may offer more power than `color-adjust()` (with the tradeoff of verbosity), but it's still limited in some ways, e.g. doesn't allow combining channels from different colors. As I expressed above, I'm now in favor of dead simple shortcuts for the common cases, which we've seen comprise the overwhelming majority of manipulations, and maximum power for the remaining few complex cases. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5782#issuecomment-747600444 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 December 2020 17:57:10 UTC