Open romainmenke opened 6 months ago
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 specifiednone
: no gamut mapping at all, all colors are clipped when out of gamutIf 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 srgbauto device
could be the default (and approximate current specified behavior), would use the current CSS GMA to map to the device gamutInstead 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.
see : https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1980976323
@ccameron-chromium said :
This comment was made in the context of gamut mapping for colors when those colors go beyond the device capability.
While I don't agree with that line of thinking, I do think there is something here and I want to explore it from a different perspective.
There is a disconnect between:
Authors can easily write CSS that produces color values that are outside specific color gamuts. With interpolation, animations, relative color, ... this can often happen without the author noticing at the time of writing that specific code.
Should it be possible for authors to force a document and/or element to gamut map all colors to a specific gamut?
Maybe through a new property :
Authors would then be able to use things like interpolation in
lch
without having to worry about unexpected outcomes on future hardware.It gives you access to the color models behind
oklch
,lch
, ... without having to think about what happens when values go beyond your design constraints.