[css-color-6] Current state of relative chroma feature in oklch()

[dokozero]

I've recently created a PostCSS plugin to upgrade oklch() notation.

The goal is to be able to set a chroma value relative to a given gamut:

oklch(gamut L RC H)

For example: oklch(display-p3 80% 100% 20) which reads as: "for a lightness of 80 % and a hue of 20, I want a color with the maximum chroma possible in the P3 gamut" and translates to oklch(80% 0.148 20).

This would be useful to avoid going out of gamut, without the need for a visual color picker, and other use cases.

It would also help designers and developers coming from HSL/HSB to use OkLCH in a more familiar way. Indeed, when discovering OkLCH, we might think that for color palettes, a.k.a. lightness variants, we just need to keep fixed absolute chroma and hue values, then simply change the lightness value, but that leads to inconsistent lightness variants.

To see the PostCSS plugin in action, get more details, advantages and use cases of this notation, please check the dedicated documentation repo.

—

I've looked at many related issue threads and saw that similar ideas were mentioned. For example: #8659 and #9449.

I didn't go for oklch(L RC of gamut H) as I took the same approach from color(colorspace c1 c2 c3) for consistency, even if it's true that in the case of oklch(gamut L RC H), gamut is only for the relative chroma RC value, not the three values.

I don't know if it's still being discussed in this repo or elsewhere. I've searched across other issues and didn't find a specific one for this relative chroma upgrade of oklch(), nor a PostCSS plugin that implements it.

Hence this issue to know where the idea stands and get feedback on the proposal.

---

For background context, I've created the OkColor Figma plugin, a color picker to use OkLCH.

At the end of 2023, I added relative chroma feature to it, this was motivated from working with OkLCH, often, I wanted to get a lightness variant, but then, I needed to manually change the absolute chroma to avoid going out of gamut.

I then realized that simply following the triangle shape in a linear path would do the job, thus adding relative chroma to OkLCH.

Then, as I was missing this feature when coding and needed to copy-paste the values from OkColor, I created the PostCSS plugin.

[svgeesus]

@LeaVerou

[romainmenke]

but that leads to inconsistent lightness variants.

Part of the issue seems to be that gamut mapping is still not implemented.
With gamut mapping the lightness shift caused by naive clipping would be eliminated.

[dokozero]

Indeed, if within a palette we use the same absolute chroma value for each lightness variant, this update would give consistent lightness progression (and prevent unwanted hue shifts).

But then for the chroma progression, relative chroma seems to be a good addition to achieve a satisfying result easily, and in that case, the clipping method would matter less as we are always in bounds (even if it's still a needed update).

Although as we can see in the example from the documentation I have recently updated, there are still some little tweaks to do if we want to craft palettes that look good together (even if not mandatory), which in that case, is also easier with relative chroma.

[facelessuser]

When speaking about tonal palettes, this might be an interesting read. https://facelessuser.github.io/coloraide/playground/?notebook=https%3A%2F%2Fgist.githubusercontent.com%2Ffacelessuser%2F0235cb0fecc35c4e06a8195d5e18947b%2Fraw%2F735d97fa895a0f9f1610189a31028b7bb1bbc2bb%2Fexploring-tonal-palettes.md.

TL;DR It basically explores creating tonal palettes in OkLCh comparing it to HCT.