[mediaqueries] In-gamut media query

[LeaVerou]

We currently have the color-gamut media query. While generally useful, this is a rather crude measure of the output device's gamut, and currently only supports RGB color spaces. Since there is no ordering of gamuts, we also cannot really have min/max-color-gamut either, either it's "approximately" P3 (whatever that means), or it's not.

I would like a to propose an in-gamut: <color> media feature, that supports any CSS color, and matches if that particular color is within the output device's gamut. This will enable authors to more accurately determine the gamut of the output device, based on what matters in their own particular use cases.

Furthermore, this will allow authors to indicate whether the color displayed is accurate or an approximation, which can matter a lot in certain applications (e.g. displaying the right color for merchandise)

Also, since we already allow providing a fallback in color() if the specified color is out of gamut, the code path to check this is already in place.

[faceless2]

You had me rushing to the spec for this one! The fallback in color() is if the original color is invalid - which I understood to be (for example) if the ICC profile it refers to is missing. I don't think it's used if it's out of gamut. Is that the intention?

Presumably to test if (for example) P3 was in-gamut, you'd have to take representative samples across the entire colorspace, convert to XYZ and then convert back to the device colorspace to see if it's clipped?

Edit: I misread, sorry. You're testing if a single color is in-gamut, not the whole colorspace. That makes quite a bit more sense. So to test if a color is in gamut, you convert to XYZ, then convert back to the device colorspace to see if it's clipped?

[svgeesus]

@LeaVerou wrote:

already allow providing a fallback in color() if the specified color is out of gamut

@faceless2 i

if the original color is invalid

Aha, both reasonable interpretations of wooly prose:

The color function takes one or more comma-separated arguments, with each argument specifying a color, and later colors acting as "fallback" if an earlier color can’t be displayed (for example, if the colorspace it specifies hasn’t been loaded yet).

can't be displayed is undefined except for an illustrative, parenthetical example.

To test a single color to be in-gamut, for additive colorspaces, you just need to check if any component is negative, or greater than 1.0 / 100%. (While using a code path that does not prematurely clip, obviously).

For non-additive colorspaces, like print, you also need to check that TAC is not exceeded.

[svgeesus]

This would be a very valuable media query. @frivoal let me know if you would like me to suggest prose text.

Removing the color-4 tag as it does not affect that specification (although it would make it easier for stylesheet authors to use that specification).

[frivoal]

@svgeesus I know just enough about colors to be dangerous. I think I know how to define this, but it might indeed be better if you gave it a shot.

[LeaVerou]

To test a single color to be in-gamut, for additive colorspaces, you just need to check if any component is negative, or greater than 1.0 / 100%. (While using a code path that does not prematurely clip, obviously).

Note that the proposal is a MQ that checks if a particular color is within the output device's gamut, not within the gamut of the color space it's specified in.

[svgeesus]

suggested text

[LeaVerou]

Nice! sRGB is a good default for screen media, but not so much for print media (if a printer can actually output the entire sRGB gamut, that's pretty impressive). I would suggest a different default for print, ideally one that is a good average of home printers (since those are the ones most likely to be missing a profile), such as an appropriate FOGRA or US uncoated SWOP, with a SHOULD so that UAs can decide a different default (or a user configurable default).

[svgeesus]

Agree sRGB is a poor choice for uncalibrated printers, even though many accept sRGB as input; they do their own gamut mapping behind the scenes in the printer driver of the printer itself.

Perhaps FOGRA29 (which is uncoated) or uncoated SWOP. Perhaps these could be specified in the same way that a profile is provided for device-cmyk (in a browser or user stylesheet)

Alternatively, given MQ uses three-value logic, perhaps it is better to return unknown?

[tabatkins]

Even if it's a lie, I think it's better for an unknown printer to pretend that it covers the sRGB gamut, as we've been printing sRGB colors to our inadequate home printers for decades.

I don't think it's useful for a print stylesheet to resolve (in-gamut: rgb(255 0 0)), say, as false, at least for a color printer.

[svgeesus]

@frivoal wrote

I know just enough about colors to be dangerous. I think I know how to define this, but it might indeed be better if you gave it a shot.

@frivoal could you review my pull request for the in-gamut MQ?

[LeaVerou]

Even if it's a lie, I think it's better for an unknown printer to pretend that it covers the sRGB gamut, as we've been printing sRGB colors to our inadequate home printers for decades.

Yes we have, and the result is a lot of puzzlement about "why does this color print so differently?".

I don't think it's useful for a print stylesheet to resolve (in-gamut: rgb(255 0 0)), say, as false, at least for a color printer

But it is out of gamut! Almost certainly unless it's some particularly fancy professional printer. Don't we want the results to be useful?

[svgeesus]

It would be easier to discuss if the proposed text was merged and we can iterate on how to handle gamut queries for printers with no gamut information later? @frivoal looking for your review, @tabatkins already reviewed it (thanks)!

[frivoal]

In case anyone is only looking here, I did review the pull request.