Add Oklab and Oklch

[foolip]

No description provided.

[foolip]

Reviewers, there are subfeatures in https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/oklab#browser_compatibility worth considering.

I think we should treat "Mix <percentage> and <number> in parameters" as a bug to possibly be present in notes when we have them.

I think "Relative Oklab colors" should be in a color-relative or color-from feature, since relative color syntax is basically the from keyword in many different contexts, supported either for all color spaces or no color spaces. (I hope.)

@romainmenke do you have thoughts on how all the new color goodness should be structured, in terms of groups and features?

[romainmenke]

do you have thoughts on how all the new color goodness should be structured, in terms of groups and features?

My current view on the evolution of the color type

[css-color-3] had fewer ways to define colors and the syntax was a bit different

• a suffixed function variants for non-opaque colors (rgba, hsla)
• comma separated values

[css-color-4] introduced a modern syntax, but this was spread out over many years.

• space separated values (2020)
• float values (2020)
• none keyword (2023)
• mixing percentages and numbers (maybe 2024)

https://drafts.csswg.org/css-color-4/#color-syntax-modern

I think we should treat "Mix and in parameters" as a bug to possibly be present in notes when we have them.

Not really a bug, more part of the general syntax refresh in [css-color-4]

none isn't tracked yet on bcd, so we should at least determine what the current status is.

modern is problematic as a name because what do you call the next version? even more modern color syntax?_

[css-color-4] also introduced a lot of new color functions, the ability to define wider gamut colors and new system colors.

[css-color-5] is more focussed on creating colors from existing colors

• relative colors (maybe 2024)
• color-mix() (maybe 2024)
• light-dark() (maybe 2024)
• contrast-color() (too early)

---

I think it might make sense to have a group for modern color syntax from [css-color-4], but it really needs a better name. Even if spread out over multiple years it is handy for authors to know if they still need to be careful with the exact syntax they use when defining color values.

---

Back to this PR :

I think that grouping by color space (oklch + oklab and lch + lab) makes sense. These are the same feature, just a different view onto that feature.

Maybe a group with all the new color functions also makes sense?

[foolip]

I made an unfortunate discovery yesterday that there's an interoperability issue with Oklab and Oklch for lightness 0% and 100% when chroma is non-zero and (as a consequence) it's outside of any RGB color space:
https://issues.chromium.org/issues/329106317

When the dust has settled on how a lightness gradient like this should behave, I think notes will be warranted for this feature, perhaps even "partial implementation" if we had that. Right now we have neither, but I'll put a comment in the file for future us to fix.

[foolip]

Thank you @romainmenke, that timeline view is helpful. I agree that a colors group would make sense when we have that. I'm glad you agree that lab + lch as its own feature makes sense, and i can send a PR for that.

[romainmenke]

Might be good to make a choice here if gamut mapping (or an alternative solution to the same issue) is a sub feature or a critical part of the implementation.

I think that authors can use all the new color functions today even without gamut mapping.
But they have to be extremely careful and have to do a lot of the work manually that the new functions are supposed to solve. From that perspective gamut mapping would be a new sub feature.

On the other hand the same input will produce a different output after the eventual solution is shipped. So that would mean the current situation is a partial/buggy implementation.

[foolip]

Might be good to make a choice here if gamut mapping (or an alternative solution to the same issue) is a sub feature or a critical part of the implementation.

If we surface this as a feature or as a note, I think we should try to describe it in as simple terms as possible. I would say the "feature" is "always goes from black to white somewhat smoothly", which no browser currently does.

I think that authors can use all the new color functions today even without gamut mapping. But they have to be extremely careful and have to do a lot of the work manually that the new functions are supposed to solve. From that perspective gamut mapping would be a new sub feature.

On the other hand the same input will produce a different output after the eventual solution is shipped. So that would mean the current situation is a partial/buggy implementation.

Yeah, since browsers now disagree about what color oklch(100% 0.15 195), and it changed in Chrome 120, something needs to be judged if we think that modifying lightness with relative color syntax is going to be at all common. I've seen it in blog posts, so I fear that it will be.

[romainmenke]

"gamut mapping" is the simplest term to describe the feature, even if that is a new term for developers.

I am concerned that any alternative description would be incorrect in various ways.

"always goes from black to white somewhat smoothly"

This only covers a tiny fraction of the problem space that gamut mapping addresses.

[foolip]

Perhaps that is the right name for it, if the description can make it clear what it is and what to look out for. If describing what has already shipped in browsers, there are only two things:

• gamut mapping with channel clipping (all browsers)
• special casing of 0 and 100 lightness (Chrome 120 and later)

Given that reality, what advice should notes give if any, if we could add notes. Is it "be very sure to stay inside of P3 or the color you see may change in the future?"

[romainmenke]

what advice should notes give if any, if we could add notes. Is it "be very sure to stay inside of P3 or the color you see may change in the future?"

If authors want somewhat stable results they can only use static values that are known to fit within srgb. p3 is off limits unless gated by @media (color-gamut: p3) {}, same for other spaces like rec2020.

They can't use color-mix with polar spaces, gradients with interpolation in polar spaces, relative colors, or arbitrary values in color channels that might go out of gamut.

Gamut mapping (as specified) is just a critical part of everything in css-color-4 and css-color-5. Most of the features do not work correctly without it.

It is not a layer on top, it is the foundation.

Authors should look out for:

• light colors that are darker than expected
• dark colors that are lighter than expected
• colors that have a different hue than expected
• gradients where the hue unexpectedly shifts
• gradients where the saturation becomes excessive
• gradients where the lightness has unexpected discontinuities
• ....

---

I think it is very tricky to think of clipping and the single hacks for 0% and 100% as things that shipped. These aren't specified features and in no way are they desirable behavior.

---

Communicating exactly what gamut mapping is in CSS and how values were initially incorrect, is just very hard when there is no consensus :/

The simpler path forward is to not do anything in particular in web-features.
Eventually they will decide on what to do with gamut mapping and then it will be easier to give the correct guidance.

[foolip]

The simpler path forward is to not do anything in particular in web-features.
Eventually they will decide on what to do with gamut mapping and then it will be easier to give the correct guidance.

This seems like the right path to me as well. We don't even have notes right now, so there's nothing I could do in this PR.

[ddbeck]

Since this is messy and I don't really understand color spaces, I've got some questions:

• Are the differences between browsers nominally in-spec? That is, are browsers incompatible with each other in ways that are a consequence of the spec being silent on the things that the browsers differ on? Or are these bugs that you could file against a specific browser even if no other browser implemented?

  If the browsers are following the spec but diverge in ways that are unpleasant to developers, then that points to the feature not meeting developer needs rather than being incompatible or poorly supported.

• Are individual support statements in BCD wrong? That is, should they be partial_implementation (or unsupported) because they don't implement the spec? Or are they wrong because the browsers do surprising but conforming things? Or is this only a concern at the level of Baseline, where we're taking a composite of several BCD entries?

As a know-nothing, I suspect something is going on here along these lines: there's a feature (Oklab and Oklch) that is kinda not great for developers, but is interoperable. In the future there might be some follow-up feature ("Gamut mapping for Oklab and Oklch"), which will make it better. But right now no such thing exists so we can't meaningfully say that browsers are missing anything at all. That said, when that new feature does appear and we hear from developers that the gamut-mapping bit is an essential part of "Oklab and Oklch support" (oklab() support notwithstanding), then we can reframe the original feature to incorporate it at that time.

[foolip]

Are the differences between browsers nominally in-spec?

While it's possible to debate what the spec really requires, the important point is that the spec editors were very clear in their intentions around gamut mapping (that it's non-optional and important to get other features like relative color syntax to work well) but implementers disagreed about the tradeoff and shipped with channel clipping. It's not an oversight or a problem of interpretation, but a disagreement about what's acceptable to ship and not.

Are individual support statements in BCD wrong?

I think we should add notes pointing to the browser bugs for gamut mapping. I don't think it should be partial_implementation because then we have to get into what the spec really requires and what the correct behavior is. When the dust settles I think we might call it partial_implementation retroactively however.

is interoperable

I thought so too, but https://crbug.com/329106317. I'm adding tests for it in web-platform-tests/wpt#45073.

The interop issue isn't gamut mapping generally, but the special handling of lightness 0 and 1. What developers need to know is that increasing lightness will eventually clamp to white in Chrome, but not in Firefox/Safari. We should be careful to not describe either as a bug, because neither behavior is actually good.

[foolip]

I've now also sent #684 for CIE Lab.

[ddbeck]

Thank you @foolip. That's very clarifying.

The interop issue isn't gamut mapping generally, but the special handling of lightness 0 and 1. What developers need to know is that increasing lightness will eventually clamp to white in Chrome, but not in Firefox/Safari. We should be careful to not describe either as a bug, because neither behavior is actually good.

Understood. Is this something we can capture in BCD, today? A behavioral subfeature, like "Black and white clamping"? If we said it was non-standard, it'd be (rightly) recognized as not-great without implying bugginess.

Also, I think I'd be happy with this merging, given the explanations above. 👍

[foolip]

I've filed mdn/browser-compat-data#22646 to get this noted in BCD.