Repository navigation
[css-conditional-5][css-color-4] @supports named-feature(gamut-mapping) #14545
Description
Problem
css-color-4 specifies gamut mapping and three different methods for doing so. Currently, no browsers have shipped gamut mapping. But if/when they do, feature detection through conventional means is likely to be limited or impossible.
Suggestion
This seems like a good candidate for a css-conditional-5 named feature for the @supports at-rule, which would overtly expose the capability for gamut mapping. This could be one named feature (e.g., gamut-mapping) or one for each method (ray-trace-gamut-mapping), though I'll defer to others' judgment on whether that level of detail should be exposed to web developers.
Motivation
For web developers, it would be helpful to be able to detect whether gamut mapping is in use (possibly by which method) and use workarounds if required.
For people like me who document the web platform, it would also be helpful to have a reliable method to determine when a browser supports gamut mapping, without resorting to manual, visual tests. This would aid data accuracy on MDN and caniuse (by way of mdn/browser-compat-data) and gamut mapping's Baseline status (by way of web-features).
Background
I'm filing this issue as a follow up to web-platform-dx/web-features#4286 (comment) (cc: @LeaVerou). This is also my first issue filed against csswg-drafts, so please advise if I need to do anything to make this issue more conventional for the CSSWG. Thank you!
Activity
svgeesus commentedon Sep 30, 2026
Enabled by default, true. However Firefox 153 shipped both
binary search with local MINDEandraytracing, behind a flag:Also Servo has
raytracing:Nope, all clear and good.
svgeesus commentedon Sep 30, 2026
There are now a couple of tests, which use rendering to canvas and then reading back the values:
[-][css-conditional-5] [css-color-4] gamut mapping `@supports(named-feature(…))`[/-][+][css-conditional-5][css-color-4] `@supports named-feature(gamut-mapping)`[/+]LeaVerou commentedon Oct 1, 2026
Yes, this seems like a no-brainer.
I don't think there are use cases for detecting the GMA used, but there are definitely use cases for detecting GM as a whole.
I'm proposing an async resolution for
@supports named-feature(gamut-mapping)ONLY and also Agenda+ to discuss if more granular features are needed (and for the whole thing in case we fail to resolve async).romainmenke commentedon Oct 1, 2026
In principle I think this is a good solution.
It might make sense to defer landing this until a while after implementations actually ship gamut mapping. I still have a lot of concerns around the current proposal (only select notations and only mapping to rec2020). I would prefer it if there is first some validation that whatever ships actually solves author and user needs. I am also very certain that initial implementations will be incomplete, like only covering spot colors while ignoring gradients, transitions, ...
astearns commentedon Oct 5, 2026
I agree with Romain. It’s likely we should have
gamut-mappingas a named feature, but given the history of implementing this feature we should evaluate implementations before giving an OK to say they@supportit.emilio commentedon Oct 5, 2026
There are multiple gamut mapping algorithms proposed. Should we have one / multiple keywords? Something else?
svgeesus commentedon Oct 5, 2026
I agree about evaluating implementations.
The gamut mapping to canvas WPT use a set of carefully selected colors and, for each, a calculated error threshold such that any of the three methods are within it, and the result of clipping is well outside it.
I could see some value in more finely-grained feature support but the major win is being able do detect whether it is available or not.