Re: [csswg-drafts] [css-color-5] Findings on SCSS function usage to inform direction of Color 5 (#5782)

@argyleink 
> > Most of the usage in SCSS etc uses HSL because that is all that is available
> 
> the problem, or gamut clamp, starts earlier than SCSS imo. starts with designers and their color tools. most designers hunt and peck inside the rgb spectrum square.. designers deliver hex, developers receive hex. eg: nearly every single "developer designer handoff tool" delivers hex colors. even most CSS [libraries](https://tailwindcss.com/docs/customizing-colors) deliver hex. it's at this point, with these values, "most" devs are in SCSS and need to darken it on hover.. without asking the ${insert dependency here}.

Libraries and tooling are going to hand off sRGB, if CSS only supports sRGB. If a value is generated anyway and edited visually, there is little value in handing off a more readable form of sRGB. However, `lch()`, `lab()`, and `color()` are not just about specifying sRGB colors a different way, they also give access to **double the colors** on modern P3 screens, which is a strong reason for tooling to change.

> and, tons of color function use is possible with css syntax today, but there's a belief that css can't do it. hsl can do most of it, but hsl is even too advanced for many people. it can't be ignored that massive amounts of scss stylesheets have code like `opacity(#000, 20%)` or `lighten(blue, 5%)` on hover. they wont see the benefits of the perceptual space work, they dont even see the edges of their gamut, the bunches of hues or the mud in their gradients. this main stream usage of ergonomic, natural language focused simplicity is all they need. "oh, css can `lighten()` now? handy! oh, docs say i can specify a colorspace, woh. maybe one day a designer will tell me which they want?". imo, they'll paste a colorspace once the tool they get their colors from has it in the easy copy button.

You may be preaching to the choir here. Indeed, most manipulations are simple, hence why both Chris and I are in favor of `lighten()` and `darken()` shortcuts (and alpha). Ideally, like every good abstraction, these should perform well and produce good results, without designers having to care how they work, whether they're using a sigmoid function, or whether they work in LCH. They don't even need to understand how LCH works. However, the fact that they don't care or understand the inner workings is no reason to have simplistic inner workings that produce poor results. They do care about the results, even if they've learned to satisfice with poor results because that's what their tools produce.
And perceptual uniformity **absolutely** matters when lightening and darkening, so that you get equal perceptual differences for an equal increase/decrease in lightness.
Furthermore perceptual uniformity is not HSL's only problem. Its components are not orthogonal, adjusting lightness can adjust the perceptual hue and saturation ([example](https://lea.verou.me/2020/04/lch-colors-in-css-what-why-and-how/#more-2934:~:text=You%20might%20argue%20that%20at%20least,it%E2%80%99s%20not%20necessarily%20the%20same%20color%3A)) 

> how much lch adoption was there in the scss source maps? i tried looking in the spreadsheet data, but saw no values?
> if it's low, let's make lch an upgrade / preference, and not a requirement. i've seen very low lch adoption in the postcss space, even though I feel i've talked about it plenty. again, i'm crazy excited for the capability, the channel interactions and apis, and overall coverage of the spec. i just can't ignore that there's engineering interest of a srgb version, engineering fear of performance implications of lch, as well as massive amounts of main stream satisfaction of srgb scss color functions.

Are you seriously suggesting we determine course of action for LCH based on its adoption in preprocessors which a) has barely been an option for MONTHS and b) has no color modification functions tied to it? c) is not even built-in, but an add-on?!
For a, as you would know from studying Almanac data yourself, things get adopted after being out there for **YEARS**. **DECADES** often. Not months!
The SCSS stats I presented here are about functions that have existed in SCSS pretty much since its beginning. They are also built-in, not a plugin. I wouldn't make any assumptions about anything based on whether people use a certain plugin-in or library.
For b, what's the point of specifying colors in LCH if you can't modify them in LCH?
For c, it's extremely rare for an add-on to appear in such stats.

The Web can't stay in sRGB forever, screens have moved past it for years now. We already can't access half of our screen colors with CSS. The "engineering fear" will need to get resolved eventually anyway, just like engineers eventually had to deal with higher pixel densities and didn't advocate that we pretend all monitors are still VGA to avoid "performance implications".

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5782#issuecomment-747139733 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 01:12:11 UTC