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

It is super valuable to see what is being used in the wild, in a massive-scale project like the Web Almanac. Since native CSS does not yet have the color manipulation functionality, being able to reach back from the deployed CSS via sourcemaps to infer the original SCSS is the only way to get at this data.

SCSS only has the ability to manipulate in HSL, so that should be borne in mid when comparing functionality. Quoting from [the HSL section of Color 4](https://drafts.csswg.org/css-color-4/#the-hsl-notation):

> An advantage of HSL over LCH is that, regardless of manipulation, the result always lies inside the sRGB gamut. A disadvantage of HSL over LCH is that hue manipulation changes the visual lightness, and that hues are not evenly spaced apart.

> It is thus easier in HSL to create sets of matching colors (by keeping the hue the same and varying the saturation and lightness), compared to maipulating the sRGB component values; however, because the lightness is simply the mean of the gamma-corrected red, green and blue components it does not correspond to the visual perception of lightness across hues.

> The hue angle in HSL is not perceptually uniform; colors appear bunched up in some areas and widely spaced in others.

> https://drafts.csswg.org/css-color-4/#the-hsl-notation

(I d suggest following the link, because Color 4 also has worked examples that show the magnitude of that effect. It is not small).

So, the `lighten()` and `darken()` usage that we have found in SCSS benefits from an advantage of HSL over LCH (any manipulation is always in gamut) and sidesteps one major disadvantage (HSL lightness cannot be compared for different hues) by keeping the hue the same.

In Color 5 we can approach that in various ways:

* I agree with Lea that we need simple  `lighten()` and `darken()` functions 
* In LCH, those will give perceptually uniform steps of lightening and darkening, but the resulting color may go out of gamut so wi trigger gamut mapping
* In LCH, adjusting the lightness and then adjusting the hue is possible *and doesn't result in the visual lightness changing* like it does in HSL
* Color 5 also offers adjustment in HSL or HWB, with the corresponding advantages and disadvantages. This would allow easy porting from SCSS to CSS, which then allows use of dynamic colors rather than the server-side static conversion.

I need to read more on how exactly SCSS computes lighten and darken (is it a simple addition or subtraction, with clamp to keep the value in range, or is there a sigmoid function).

I also see some [criticism of  `lighten()` and `darken()`](https://codepen.io/joshmcrty/details/OVZbBr):

> Sass has color function to lighten and darken colors, but these don't always behave the way you might expect. Using mix() with black and white can produce more predictable results.

So that needs to be investigated. Mixing in white or black sounds like manipulation in HWB, or using `color-mix()`

The point about extracting, manipulating, and re-inserting color components is interesting. It also allows the manipulation to be done in JS, as an extensibility point. We should definitely explore it. In SCSS, re-inserting is free because it is just string concatenation; we would need a way to enable re-creating a color from components.

> Would things like `lch-hue()` be too verbose? Should we have a generic `hue()` for LCH and a `hsl-hue()` for HSL?

I don't have a strong opinion on the naming, but yes they do need to be distinct (the same color has very different hue angles in different systems). I have a slight preference for  `lch-hue()` both as self-documenting and also so if we get a better colorspace than Lab/LCH in the future, we are not stuck with "`hue` means hue in LCH for historical reasons".

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


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

Received on Friday, 11 December 2020 16:24:05 UTC