[css-color] Add OkHSL

[Ptico]

The CSS Color 4 already have an OkLAB and OkLCH which is great step forward, but it turned out not everyone is aware @bottosson have created OkHSL and OkHSV as well. This color spaces combines the benefits of HSL and OkLAB:

1. Human friendly — it is easy to calculate or build a desired color just looking at numbers without having a PhD in physics
2. Scripting ability — generate color palettes just by rotating an H component
3. a11y — possibility to derive a color with exact desired color contrast

The only downside: unlike OkLAB, OkHSL is limited to sRGB and i'm not sure if it possible to scale it to the wide gamut. Anyway, it worth to at least discuss this.

@LeaVerou

[svgeesus]

No-one needs a PhD. However, OkHSL and OkHSV also inherits the disadvantages of HSL and HSV - being forced into a regular geometric solid means the color spaces are no longer perceptually uniform. Which is the entire point of Oklab.

Being restricted to sRGB, at the exact time that the Web is strongly moving to display P3, is also a significant limitation.

Could you explain more about the "exact desired color contrast" part?

[Crissov]

I understand how …HSL/V feels more intuitive to use than …Lab, but what’s their UX advantage over …LCH?
Is it that hue does not come first?

I once proposed that the order of components be relaxed where possible due to different dimensions (e.g. support °%% and %%°), but with the units being mostly optional (and with none), this does not work well.

[LeaVerou]

I understand how …HSL/V feels more intuitive to use than …Lab, but what’s their UX advantage over …LCH? Is it that hue does not come first?

I believe it is that every combination of values within range is in gamut.

[Ptico]

No-one needs a PhD. However, OkHSL and OkHSV also inherits the disadvantages of HSL and HSV - being forced into a regular geometric solid means the color spaces are no longer perceptually uniform. Which is the entire point of Oklab.

That's is the point of OkHSL — it does cut boundaries to be fit in a geometric means, so yes, you loose some peak values but stay perceptually uniform

Being restricted to sRGB, at the exact time that the Web is strongly moving to display P3, is also a significant limitation.

Yes, that's a big disadvantage and if it's can't be stretched to P3 — this is strong argument against. Curious to hear @bottosson about this.

Could you explain more about the "exact desired color contrast" part?

It's relatively easy (at least I did this before with HSLuv and WCAG 2 contrast ratio) to calculate an L shift to derive a color with defined contrast ratio. So, for example, if you have a background color and need a color for text with the same H and S with 4.5:1 contrast ratio, you can calculate the L

[Ptico]

I understand how …HSL/V feels more intuitive to use than …Lab, but what’s their UX advantage over …LCH? Is it that hue does not come first?

I believe it is that every combination of values within range is in gamut.

@Crissov yes, it's all about the range shifts with any of the component change, so the palette building looks like the famous Family Guy CSS meme

[facelessuser]

I'm not going to comment on whether CSS should adopt Okhsl. Okhsl is an approximation of the sRGB gamut and isn't precisely all in gamut. I'm not 100% sure if it fits what CSS is looking for, but I can't really say. But if you want to calculate a value in Okhsl that maps to OkLCh, using a tool is easy enough, and I'm sure more may pop up in the future.

I'm not saying whether this is a good idea or not, but I'm going to answer this question because it sounded like fun to try.

Yes, that's a big disadvantage and if it's can't be stretched to P3

So, it can be switched to P3. All of the information needed was provided by bottosson and can be found in the Okhsl/Okhsv blog. Particularly this code which was used to tune the constants for approximating the sRGB gamut. Simply calculate the matrices for P3 <-> LMS, plug them in, and generate the new constants needed. I used this script to ensure the Okhsl implementation I support tightly integrates with the adjusted Oklab matrix we use that aligns with the CSS white point.

Once you have the constants, you can operate in the P3 gamut using the Okhsl model:

Let's do a sanity check. Okhsl P3 should use the same hue that OkLCh does, but it should have an adjusted lightness and saturation. Fully saturated red, green, and blue should sit on the edge of saturation as well.

>>> Color('display-p3', [1, 0, 0]).convert('oklch')
color(--oklch 0.64857 0.29949 28.958 / 1)
>>> Color('display-p3', [1, 0, 0]).convert('okhsl-p3')
color(--okhsl-p3 28.958 1 0.59189 / 1)
>>> Color('display-p3', [0, 1, 0]).convert('okhsl-p3')
color(--okhsl-p3 145.64 1 0.82405 / 1)
>>> Color('display-p3', [0, 0, 1]).convert('okhsl-p3')
color(--okhsl-p3 264.05 1 0.38284 / 1)

Yep, everything checks out. You can see it working live here. If you have a P3 monitor, and are using the latest Chrome or Safari, it should show genuine P3 colors.

I haven't tested this beyond generating the 3D model and doing a basic smoke test, but it seems like its working well enough.

[facelessuser]

Adjusted demo to also implment Okhsv.

You can see the differences in normal Okhsv trying to represent P3 colors vs Okhsv P3 which now fits it nicely:

I don't know if people are seriously clamoring for a P3 Okhsl/Oksv, but if they are, this shows it is possible to implement both.

[eeeps]

I think a lot of times people picking or modifying colors in code want to use intuitive, normalized 0-100% scales. Perceptual uniformity isn't important for those cases, although orthogonal H, S, and L dimensions are. As Björn’s post on the subject points out, you can't have orthogonal dimensions and normalized values, but maybe we can have better tradeoffs than hsl() or oklch() currently offer for this "intuitive colors with code" use case.

Mostly I want a notation that allows me to pick a gamut, pick a hue, and then use 0-100% S+L ranges within that gamut. This isn't possible right now because:

• OKLCH has a lumpy shape and it's impossible to intuit what the maximum L and C values are for any H/gamut combo
• HSL is limited to the sRGB gamut (also it is particularly not-orthogonal)

I want something where like magicHSL( rec2020 20deg 100% 50% ) might represent ~oklch(50% 0.26 20deg) but magicHSL( sRGB 20deg 100% 50% ) might represent ~oklch(50% 0.22 20deg).