Thanks for reporting, and please make sure to follow our Community Participation Guidelines to ensure respectful collaboration.

We're currently in the process of adding general BCD guidelines for partial_implementation, and the reported issue does not meet the proposed criteria for marking the features with partial_implementation, because all implementing browsers appear to implement the feature in the same way, so their behavior is consistent, and the implementations can be considered de facto complete, even if they diverge from the spec.

We can capture spec changes (or aspects) in a behavioral subfeature though.

@pygy Would you suggest to capture support for "Gamut mapping" as a subfeature, or specific behaviors like "Maps lightness of 0% or 100% to black and white"?

I hope that denouncing ablism (systemic or otherwise) doesn't break the guidelines. Apologies if I crossed a line.

The proposed criteria are exactly part of what I was thinking about when mentioning the systemic aspects of the issue. They make sense in isolation, but combined with other factors, they perpetuate the problem. I'll chime in over there. Flouting accessibility should IMO be a deal breaker when it comes to considering a technology supported. Edit: also please note that the respective issues in the trackers are still open, meaning that implementors don't consider the issue as settled.

I don't think splitting (e.g. black/white, and other colors) this would make sense, as this goes beyond white/black.

Per spec, browsers should do with out of gamut colors, to preserve the contrast:

Currently they do this (clamp(RGBChannel, 0.0, 1.0)) roughly this, visually:

OKLab is future-proof, in that it supports all possible future display technologies better gamut that we have now, but it lets authors specify colors that are wildly out of the supported range. The current algo leads to contrast compression.

We end up with this (imagine this is a Web page with text, note that the flowers are ~uniform):

When we could have this with proper mapping:

Images source : https://bottosson.github.io/posts/gamutclipping/ , except for the schema that illustrates RGB clipping, which is mine.

Thanks for sharing the visualisation.

Per spec, browsers should do with out of gamut colors, to preserve the contrast:

Can you link and cite the relevant extract from the spec that describes the clamping as you expect it?

Issues around gamut mapping came up in the process of combining these keys into a feature for web-features. There's a rather long discussion on it, but the interesting part for BCD starts with web-platform-dx/web-features#674 (comment) through the end of that PR.

At the time the oklab feature shipped in browsers, implementers disagreed about what the spec required and so implemented clamping behavior as a substitute (at the time there was debate about whether this was allowed by the spec, so Philip and I couldn't even say that the clamping behavior was non-standard or not).

Today, it's a little more clear cut: the clamping behavior is compatible but non-standard. Resolving #22646, with notes or by creating a non-standard behavioral subfeature, would cover some of the matters described here in this issue. As far as I can tell, there are no implementers of the latest specification text that actually calls for full gamut mapping, so there's probably nowhere to describe anything as partially implemented (until one browser does implement the new text, at which point the other implementers would become retroactively partial).

Notes would be nice though!

Thanks, Daniel.

@pygy Would you like to update your PR to use either a non-standard behavioral subfeature for "Gamut clamping", or notes describing the limitation without the partial_implementation flag? I would strongly recommend using a non-standard behavioral subfeature, because it will be more visible (a separate row in the BCD tables on MDN). 🙏