[css-color-4] Do we actually need hwb()?

[LeaVerou]

hwb() was added to CSS Color over 8 years ago, when we still thought sRGB-only formats and manually tweaking components to create variations were the way to go. The theory was that because its two non-hue components are whiteness and blackness, it would make it easier to create tints and shades of colors.

After going unimplemented for 8 years, it was now implemented in Gecko and WebKit alongside other things in Color 4, but its usage on the web is still 0, so there is no web compat risk in removing it.

Here’s why I think we should remove it:

• We shouldn't be adding new sRGB-only color formats (and even though this has been in the spec for 8+ years, it's new in browsers), instead we should gently guide authors away from the existing ones.
• Color modification is now moving in a different direction and (OK)Lab/LCH are far superior for creating variations of an existing color and color-mix() is far superior for creating tints and shades (mixes with white and black) of any existing color.
• It's not like there's any tooling that uses HWB either so we don't need to keep it around for compat with that.
• It would allow us to close 2 issues

So let's kill it with fire! 🔥🔥🔥 Who's with me? 😃

[SebastianZ]

I'd be a bit sad as I just implemented DevTools support for it in Firefox. And I believe it's a good sign that hwb() finally got implemented in browsers, as it shows that there is implementer interest for the suggested color features, after all.

And couldn't hwb() be seen as a shortcut for color-mix() in combination with hsl()? E.g. hwb(240 50% 30%) expressed with color-mix() is color-mix(hsl(240 0% 0%), white 50%, black 30%)), right?

The mentioned two issues do also apply to other color functions, so they can't be closed just because of the removal of hwb().

Though from my question above you can see that I am everything else than a color expert. 😊 So @LeaVerou, when you say hwb() is not needed by authors, I trust you.

Sebastian

[LeaVerou]

And couldn't hwb() be seen as a shortcut for color-mix() in combination with hsl()? E.g. hwb(240, 50%, 30%) expressed with color-mix() is color-mix(hsl(240, 0%, 0%), white 50%, black 30%)), right?

See, that's precisely what I’m worried about. No, it's not a shortcut for color-mix(). color-mix(white X%, var(--color)) can produce any tint, whereas hwb() is restricted to the sRGB gamut.

Note that color-mix(hsl(240, 0%, 0%), white 50%, black 30%)) is invalid syntax, as the color space argument is mandatory and color-mix() only allows up to two colors. But assuming you meant color-mix(in hsl, color-mix(in hsl, hsl(240, 0%, 0%), white 50%), black 30%), that would give you gray, not purple like hwb(240 50% 30%), since you're mixing black with white and black…

[tabatkins]

My only real argument for maintaining HWB is that color pickers in many applications continue to use it as their input form, which suggests it continues to have some use. Chrome at some point switched to an HSL-ish form for <input type=color> and its DevTools colorpicker, but in the past used the "triangle and circle" HWB-style picker. I was just watching an artist's stream on Twitch the other day, tho, and whatever drawing program they were using still used triangle-and-circle, too.

We shouldn't be adding new sRGB-only color formats (and even though this has been in the spec for 8+ years, it's new in browsers), instead we should gently guide authors away from the existing ones.

Valid. I wouldn't be too put out removing HWB, due to this precise reasoning.

Color modification is now moving in a different direction and (OK)Lab/LCH are far superior for creating variations of an existing color and color-mix() is far superior for creating tints and shades (mixes with white and black) of any existing color.

Not really, at least for the case HWB is for. LCH and HSL are identical in terms of ease of creation/manipulation, and manipulating colors in HSL being kinda tricky is exactly why HWB exists; it's (reasonably, imo) argued that the lightness/saturation(chroma) plane is harder to work with, mentally, than the HWB triangle.

color-mix() isn't a substitute for readability/authorability, either, because you have to stack two of them together and it's way longer as a result. It is indeed easy to generate tints and shades from a base color out of it, which isn't what HWB was for anyway. (HWB made it reasonably easy to manually generate tints and shades of a base color that was already expressed in HWB, but had no ability to manipulate arbitrary colors.)

It's not like there's any tooling that uses HWB either so we don't need to keep it around for compat with that.

Kinda sorta (see first paragraph) - the HWB mental model appears to still be used in quite a bit of tooling (but so is the HSL mental model)

It would allow us to close 2 issues

I don't understand what you mean by this. The older of these issues is about both HSL and HWB, so you either can't close it (because it's unanswered for HSL) or can (because it's answered for both). The more recent one, about commas, was originally asked purely about HWB, but is also in fact about multiple color functions (all the recent ones), so again either we can close it because it's answered for everyone, or we can't close it because it's not answered for any of them. We have no open issues actually about the hwb() function itself, such that removing it would let us auto-close anything.

[SebastianZ]

And couldn't hwb() be seen as a shortcut for color-mix() in combination with hsl()? E.g. hwb(240, 50%, 30%) expressed with color-mix() is color-mix(hsl(240, 0%, 0%), white 50%, black 30%)), right?

See, that's precisely what I’m worried about. No, it's not a shortcut for color-mix(). color-mix(white X%, var(--color)) can produce any tint, whereas hwb() is restricted to the sRGB gamut.

Sure, but if you specify in hsl or in rgb you restrict it to sRGB.

Note that color-mix(hsl(240, 0%, 0%), white 50%, black 30%)) is invalid syntax, as the color space argument is mandatory and color-mix() only allows up to two colors. But assuming you meant color-mix(in hsl, color-mix(in hsl, hsl(240, 0%, 0%), white 50%), black 30%), that would give you gray, not purple like hwb(240 50% 30%), since you're mixing black with white and black…

What I wrote was total nonsense. My question was rather, how to express e.g. hwb(240 50% 30%) with color-mix() and/or lch()?

Sebastian

[svgeesus]

Chrome at some point switched to an HSL-ish form for and its DevTools colorpicker, but in the past used the "triangle and circle" HWB-style picker. I was just watching an artist's stream on Twitch the other day, tho, and whatever drawing program they were using still used triangle-and-circle, too.

A triangle with black at the bottom, white at the top, and the most saturated/high chroma color of a given hue as the third corner is a natural representation of a constant-hue slice through a color gamut. Perceptual representations will have varying shaped triangles (and may have curved edges) while not-really-perceptual ones will go for a regular isosceles triangle.

There are several examples n the spec already, such as
https://drafts.csswg.org/css-color-4/images/OKLCH-blue-slice.png

Given a constant-hue presentation, there then needs to be a separate means to select the hue and a circle is the natural way to indicate this.

Which is to say that

1. Triangle-circle representations are common and natural, and
2. They are unrelated to HWB, they apply to any polar colorspace.

LCH and HSL are identical in terms of ease of creation/manipulation

Not really, and the spec already makes that very clear:

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.

[svgeesus]

• It would allow us to close 2 issues

Those issues are close to being closed anyway; the commas in HWB one is just waiting for me to add wording about all the other commaless syntaxes not having an equivalent with-commas form, but the spec is already explicit about HWB not allowing commas and WPT tests are already updated to reflect that.

[tabatkins]

A triangle with black at the bottom, white at the top, and the most saturated/high chroma color of a given hue as the third corner is a natural representation of a constant-hue slice through a color gamut. Perceptual representations will have varying shaped triangles (and may have curved edges) while not-really-perceptual ones will go for a regular isosceles triangle.

Hm, my point is that the "rectangle" view is an accurate representation of the coordinate space - for a given hue, you can specify colors in the (high chroma, high lightness) and (high chroma, low lightness) corners. HSL actually treats these colors as meaningful, which is nonsense, of course, but it does make for a very simple way to represent the coordinates, and that's equally true for LCH (it just doesn't pretend those colors outside the triangle-ish area are real). The triangle only arises by specially marking the out-of-gamut colors; they're still possible to specify.

I suppose technically HWB's equal-hue slices are the same if you were to just map them to a square with W/B axises, but it feels like that's not a natural interpretation of the coordinates; for one, it puts the pure hue off in a corner. The triangle, representing weights of the three colors (or equivalently, with the altitude from the hue-corner representing w+b %, and then perpendicular distance representing w% vs b% balance), represents it well; it omits some values you can technically specify, but only redundant ones that can be specified in other ways.

LCH and HSL are identical in terms of ease of creation/manipulation

Not really, and the spec already makes that very clear:

In the sense I am meaning, yes really - both of them model colors with the "saturation(chroma) + lightness" model; the entire point of HWB is the assertion that this isn't a very natural model to think in, and that "hue + white + black" is more natural.

I'm well aware of the differences between HSL and LCH and why LCH is a marked improvement, but those differences aren't relevant to what I was saying.

---

Again, I know that HWB is a non-perceptual space; it's just a recasting of HSL, which is just a recasting of RGB. I'm not defending it on those grounds; that would be silly. I'm just pointing out that it does have reasons to exist, which aren't met by the other new color functions.

[svgeesus]

@LeaVerou wrote:

After going unimplemented for 8 years, it was now implemented in Gecko and WebKit alongside other things in Color 4, but its usage on the web is still 0, so there is no web compat risk in removing it.

True, hwb() usage (from the 2021 Web Almanac) is (currently extremely low](https://docs.google.com/spreadsheets/d/12vQIA0xsC5Jr3J9Sh03AcAvgFjMAmP1xSS6Tjai9LF0/edit#gid=1391098015)

But so is color(), currently. And indeed hsl() barely makes it to 1%.

[svgeesus]

I'm not hearing a compelling reason to remove hwb() and hearing some support for retaining it. Can I Use says it is implemented in Gecko and WebKit and wpt agrees that Blink doesn't implement it yet.

@tabatkins is Blink expected to show up in Blink at some point? I couldn't find a bug for it.

Given two independent implementations in browsers, there is n reason to put it at-risk and I am inclined to just leave it as-is with no spec change.

[SebastianZ]

@tabatkins is Blink expected to show up in Blink at some point? I couldn't find a bug for it.

I've filed one now: https://crbug.com/1288883

Sebastian

[tabatkins]

[web almanac data]

lol, I wonder what that one page that's using hwb() is.

[svgeesus]

Given no objections, and also evidence that Blink is implementing hwb(), closing with no action