So to clarify, this is a gamut map on all computed color values, before the mapping to the actual display?

Yes.

Would the default value be none, or some specific gamut?

I think it must be none as it is unlikely to be changed in the future for web compat reasons.

If authors want to limit to a specific gamut then they must state so explicitly.

Thanks for confirming @romainmenke!

Would this property define how colors outside the specified gamut are gamut mapped into it?

Does it apply to all elements?

Can it be animated?

Would this property define how colors outside the specified gamut are gamut mapped into it?

I imagine so, yes. Not much use in guaranteeing predictable colors if different browsers can still render differently.

Does it apply to all elements?

Yes, it would need to.

Can it be animated?

I don't see a compelling reason to allow that. It should just animate discretely.

I don't see a compelling reason to allow that. It should just animate discretely.

Same here, just wanted to check.

Thinking about this more, this same property could also be an opt-out of gamut mapping.

Values could be:

• srgb | p3 | rec2020
• auto
• none

Where:

• auto : css gamut mapping algorithm as currently specified
• none : no gamut mapping at all, all colors are clipped when out of gamut

If clipping is valuable to some an opt-out could be a way to move forwards.

none is different than clip, I think. none would tell the user agent to leave the color as is, outside of the display gamut, essentially leaving it up to the display hardware (or whatever graphics API the user agent is interacting with) to clip, do its own gamut mapping, or error in some way.

I think we would need multiple values, with some shorthands. Essentially, we are defining a path to a color that can be displayed on a user's device, so we need method destination gamut, method destination gamut, .... We must end on the device gamut or smaller (unless we want to allow a none escape hatch?) so we need to implicitly add those final steps if the user doesn't specify it.

For instance-

• auto rec2020, clip would use default GMA to map to rec2020, and then clip to the device as needed.
• clip p3 would clip to p3.
• clip rec2020, auto p3, clip srgb could be possible, clipping to rec2020, then default GMA to p3, then clip to srgb.
• auto device, clip srgb would use the default GMA to get to the device gamut, and then do an additional clipping to srgb
• auto device could be the default (and approximate current specified behavior), would use the current CSS GMA to map to the device gamut

Instead of clip and auto, it could be useful to have intent-based names, for instance preserve-contrast instead of auto and preserve-chroma instead of clip?

This does raise the burden on implementers to implement multiple algorithms, mapping to multiple gamuts.