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.
css-meeting-bot commentedon Oct 30, 2026
The CSS Working Group just discussed
[css-conditional-5][css-color-4] `@supports named-feature(gamut-mapping)`, and agreed to the following:RESOLVED: Add `gamut-mapping` feature, and a note summarizing concernsThe full IRC log of that discussion
<emilio> lea: it's taken enough time to ship gamut mapping that we need to detect whether it's present, otherwise they limit how they can use color<emilio> q+
<emilio> ... e.g. if they're creating scales for an accent color, gamut mapping makes it easier
<emilio> ... but as an author I'd like to detect and fall back to desaturating or so if gamut mapping is not present
<emilio> ... we need to provide some way to detect it, needs to be a named feature
<emilio> ... we can always add more granular things later
<emilio> ... but main thing would be any gamut mapping is present
<JohnJansen> ack emilio
<romain> q+
<emilio> emilio: it's easy to do, though I'm a bit skeptic that people are going to use it? Usually named features are for when not having the feature would break badly
<TabAtkins> lea: there are cases where things are broken, it's not just aesthetic. a11y can be broken because distinct colors become too close togher or identical.
<TabAtkins> emilio: do things break between mapping algos? do you care which one?
<TabAtkins> lea: they're designed so the diffs are small and generally wont' matter
<TabAtkins> lea: Firefox does this thing where it gamut-maps to rgb even on a p3 screen, but that' s detectable with (color-gamut)
<TabAtkins> lea: so it could still be buggy but that's true of all new features, this isn't a unit test
<JohnJansen> ack romain
<TabAtkins> lea: this is also separate from canvas, you can detect mapping gin canvas so we dont' need it there
<TabAtkins> Romain: I agree with this but I would like to defer adding it
<astearns> q+
<TabAtkins> romain: I think there will be many issues filed against gamut mapping because the space is so massive
<lea> qq+
<TabAtkins> romain: too many cases in Firefox, especially in gradients, where the results are too variable
<emilio> q+
<TabAtkins> lea: if we hold it back too long it loses its value. authors want to use features when they're there
<JohnJansen> ack lea
<Zakim> lea, you wanted to react to romain
<TabAtkins> romain: the added value is when it works. if it doesn't work yet, then people need to care about that
<TabAtkins> emilio: so it does matter what gamut mapping to use?
<TabAtkins> astearns: no, Romain means it matters *where* it applies
<TabAtkins> emilio: I think we apply mapping to gradients?
<TabAtkins> romain: the spec says "do gamut mapping", not strict details about exactly when it happens
<lea> qq+
<TabAtkins> romain: so it's a little handwavey and i'd like to see some eimpl experience
<JohnJansen> ack astearns
<emilio> ack emilio
<TabAtkins> astearns: I think a way forward is to specify this, but then enumerate the ways in which gamut mapping must be supported before this can be considered true
<TabAtkins> astearns: not as concerned about bugs
<florian> q+
<emilio> q+
<JohnJansen> ack lea
<Zakim> lea, you wanted to react to lea
<TabAtkins> astearns: but if an engine decides they'll support mapping in stages, starting with 'color' but maybe not gradients yet, they shouldn't be allowed to say "true" for the feature
<TabAtkins> lea: one thing i'm seeing is that while the mapping algo doesn't matter much, the use-case can matter
<TabAtkins> lea: so the way forward might be a specialized function, not a named feature
<romain> q+
<TabAtkins> lea: so you can ask for specific things
<TabAtkins> lea: gamut mapping works well right now for plain colors, and I don't want gradients to delay that until we get everything perfect
<TabAtkins> lea: so if we need some way to distinguish that support, that's fine
<TabAtkins> lea: we could even add canvas to the list of values later, even
<JohnJansen> ack florian
<TabAtkins> (we can just add more keywords if needed fwiw)
<TabAtkins> florian: meta-comment, but this is why initially when we designed @supports we didn't want to have an explicit list and answer tricky questions
<TabAtkins> florian: in general let's use restraint with how many things we add where it's *possible* to debate support
<astearns> +1 to not proliferating named features
<TabAtkins> florian: this isn't an objection about doing this, we've crossed the bridge, but be careful when we do
<lea> q+
<JohnJansen> ack romain
<TabAtkins> romain: I don't think... in Firefox it's not doing colors and, separately, doing gradients. it's the whole thing
<florian> s/and answer tricky questions/and answer tricky questions, and limited ourselves to "does this parse"/
<TabAtkins> romain: and i'm not concerned by impl bugs, i'm concerned about conceptual errors. are we speccing the right things? problem space is so large that it's hard to predict the outcome. that's why I want feedback from authors
<astearns> for the record, ChrisL is in favor of @supports named-feature(gamut-mapping)
<JohnJansen> ack emilio
<TabAtkins> romain: so I'm just not sure we've covered the entire thing
<TabAtkins> emilio: confirming what Romain said, the confusing behavior is that we gamut-map the specified colors, then we interpolate them on the GPU, and we can't gamut-map the eintermediates the same way
<TabAtkins> emilio: to me it feels like... would that actually prevent you from using it? doesn't seem like a common enough use-case for this keyword to stop being useful
<astearns> q+
<TabAtkins> emilio: I wouldn't oppose holding off on shipping the named feature, but...
<TabAtkins> emilio: you either get author feedback before shipping, where we are now. or we get it afterwards
<TabAtkins> emilio: it seems like you're asking for something in the middle
<TabAtkins> emilio: if the existing algos unlock most of the value of the feature, i'm fine with shipping the named-feature
<JohnJansen> ack lea
<TabAtkins> lea: another direction that might be palatable and useful is, instead of having a named-feature, introduce a color() function that introduces the gamut-mapping Algo for a specific color space
<TabAtkins> lea: and have a MUST in the spec that UAs must implement this at the same time as mapping
<TabAtkins> lea: then authors can use the function to detect support
<TabAtkins> lea: and can use conditionals to detect exactly what colors map to, do operations on the mapped color...
<TabAtkins> lea: like if you create color scales, for the lightest color you don't want to just set 97% lightness and then step the rest. you look at designer-created scales, you want to get a little bit lighter
<fantasai> mapped-color() ?
<TabAtkins> emilio: it seems like that's orthogonal to what Romain is saying, which is that mapping the colors you specify might not be enough
<TabAtkins> romain: sharing screen, top bar is what Firefox is doing
<TabAtkins> romain: so I want to see feedback whether this is acceptable or not
<TabAtkins> emilio: okay, but still we can only get feedback before or after shipping
<TabAtkins> emilio: are you arguing for holding off on shipping the mapping? or ship mapping but not the named feature?
<TabAtkins> emilio: I think that's a bit harder to argue. if the feature is useful, it seems detecting it is useful
<TabAtkins> romain: I think it's a bit troubling i'm the only one raising problem cases like this
<lea> q?
<lea> q+
<TabAtkins> romain: so if people aren't raising these issues, people aren't using nightly and turning on the flag
<JohnJansen> ack astearns
<TabAtkins> romain: this isn't that bad, I just want more feedback before we stamp it as working as intended
<TabAtkins> astearns: Elika pointed out we want to avoid a v1, v2 keyword version
<TabAtkins> astearns: also, chair hat off, I'd like to walk back my support for romain's point. I think it's okay to have a gamut-mapping named feature that has a certain amount of caution in the spec - make sure you have a reasonably complete mapping impl before you say yes to the feature. but there's gonna be problems
<TabAtkins> astearns: bugs that'll be addressed
<smfr> q+
<TabAtkins> astearns: we'll eventually be at a point where the named-feature is fully reliable for devs, but making some mistakes along the way will get us there sooner
<JohnJansen> ack lea
<TabAtkins> romain: it's a temporary problem
<TabAtkins> lea: q about romain's demo - is this interpolating between oog colors? or using in-gamut colors whose interpolation is out?
<TabAtkins> romain: the specified colors are out of spectral locus
<TabAtkins> romain: when any color is outside the locus, you can get artifacts like this, it's not about the interpolation
<TabAtkins> lea: are you saying mapping single colors outside the locus gives these results?
<TabAtkins> romain: that's something i've been experimenting with. doing a clip to the locus reduces these artifacts
<TabAtkins> lea: if the bar for this feature is that it's bug-free, that's very high
<TabAtkins> lea: but as I was saying earlier, having the way to invoke mapping explicitly would be a useful feature anyway
<JohnJansen> ack smfr
<TabAtkins> smfr: ideally when we add the named-feature we have a set of WPTs that tell us the named-feature and what goes together with that
<fantasai> +1 smfr
<lea> s/explicitly would be a useful feature anyway/explicitly would also let you gamut map *before* interpolation/
<JohnJansen> ack fantasai
<TabAtkins> smfr: that runs into the next issue, testing gamut mapping
<TabAtkins> fantasai: couple of points
<TabAtkins> fantasai: is nightly shipping with it on?
<TabAtkins> emilio: currently flagged off
<TabAtkins> fantasai: okay shipping it on might get you more feedback that Romain is looking for
<TabAtkins> fantasai: next, I agree with Simon we should have a set of core tests that you need to pass before you should turn the enamed-feature on
<TabAtkins> fantasai: as to how to test, it might be manual testing
<TabAtkins> fantasai: we have a clever test from dbaron about testing box-shadow
<TabAtkins> fantasai: using a gradient above and below, clipping a small chunk of the shadow, saying it passes if the shadow is between the two gradients
<lea> PROPOSED: Add some way to feature detect gamut mapping, TBB what that is
<TabAtkins> JohnJansen: and that's a detail we'll talk about in the next issue
<TabAtkins> JohnJansen: so we have a request to pause the named-feature for now since it would be somewhat misleading for now
<TabAtkins> JohnJansen: thoughts? could explore alternatives in the issue
<fantasai> PROPOSED: Add named-feature() that requires passing a particular set of WPT tests TBD. ?
<romain> +1
<TabAtkins> astearns: we do all want to have this, unsure it's valuable to resolve that we do want to do it
<TabAtkins> JohnJansen: Elika proposed a different resolution, requiring a specific set of tests
<TabAtkins> JohnJansen: that would probably fix this issue?
<TabAtkins> lea: I think this establishes a weird precedent, we don't do this for any other named-feature
<romain> q+
<TabAtkins> lea: if the feature is buggy we fix the bugs. we haven't set these conditions for anything else.
<TabAtkins> fantasai: I think that's because for everything else, the q of whether we support it is generally "do we even parse it". this is a much more fuzzy/quality thing
<JohnJansen> q+
<TabAtkins> fantasai: so I think this is reasonable. not "all WPT tests", but a small set that test the core aspects
<TabAtkins> fantasai: I think that's pretty reasonable
<JohnJansen> ack romain
<TabAtkins> romain: I was thinking of other named-features, they generally were already shipping a while and only later got the naemd-feature. this I think is our first named-feature for something new
<TabAtkins> romain: I was thinking maybe it should require two impls, or ship for N months, etc
<TabAtkins> JohnJansen: I don't think we should try and change the meaning of named-feature
<TabAtkins> JohnJansen: if we change these details, we're edging into the space of "this should be fully mature recommendation"
<astearns> PROPOSED: Add named-feature(gamut-mapping) with a note summarizing all of these concerns
<JohnJansen> ack JohnJansen
<TabAtkins> fantasai: there *are* requirements about whether you can parse something. if you don't have a usable level of support you can't parse
<TabAtkins> fantasai: so there's some level of judgement on the part of the UA - do I support *enough* before they flip on parsing (and thus @supports
<TabAtkins> fantasai: we've had to tell impls to back out parsing support because their impl was too broken/incomplete
<TabAtkins> fantasai: named-feature is less tightly coupled, so we need to defined what it means
<TabAtkins> fantasai: doens't necessarily have to be WPT, can just be a list of requirements. needs to be as granular as that tho - map gradients in this way, map spot colors in this way, etc
<TabAtkins> JohnJansen: sound slike Lea's proposed direction?
<TabAtkins> fantasai: lea's proposal was vague
<lea> q?
<TabAtkins> fantasai: there are many ways to do feature detection. for example, she proposed introducing a new color-mapping function, and require that to be tied to general gamut mapping, so then you can do parsing test for the function
<lea> q+
<lea> +1 to proposed resolution
<TabAtkins> JohnJansen: Alan also proposed a resolution a bit up, have a note with these concerns
<lea> s/+1 to proposed resolution/+1 to astearns proposed resolution/
<TabAtkins> astearns: i'm moving the tbsp to non-normative text
<TabAtkins> q+
<TabAtkins> s/tbsp/tbsp/
<JohnJansen> ack lea
<TabAtkins> s/tbsp/tbd/
<TabAtkins> lea: one downside of tying gamut mapping to the function is function would be easiser, and can help us design general gamut mapping
<JohnJansen> ack TabAtkins
<romain> +1
<emilio> TabAtkins: I think we can go with alan's proposal
<emilio> ... support what fantasai was saying, while there is a bit of judgement, what you must do for support is parsing is relatively minimal
<emilio> ... and we should not be more strict for the named feature
<emilio> ... this is for the things that can't be for parsing
<emilio> ... it needs some judgement, we can have notes for what we consider to be usable
<emilio> romain: I don't feel so strongly, the burden shouldn't be excessively high
<emilio> ... but we need author feedback
<emilio> PROPOSED: Add `gamut-mapping` feature, and a note summarizing concerns
<emilio> RESOLVED: Add `gamut-mapping` feature, and a note summarizing concerns
<TabAtkins> s/can't be for parsing/can't be detected via parsing/
[css-images-4] Require out of gamut colors in gradients to be css gam…
[css-conditional-5] Change spelling of named feature from gamut mappi…
svgeesus commentedon Nov 2, 2026
See https://drafts.csswg.org/css-conditional-5/#support-definition-named-features
I also updated Color 4 to talk about how interpolation can produce out of gamut colors, and Images 4 to reference Color 4 for color interpolation and for gamut mapping, and to make gamut mapping out of gamut colors in gradients an explicit must.
svgeesus commentedon Nov 3, 2026
@ddbeck please confirm that this satisfies the issue.
ddbeck commentedon Nov 5, 2026
This works for me. Thank you!