Color gamut `srcset` descriptors (and Client Hints, too)

Better-than-sRGB displays are here; <picture> + color-gamut media queries let us use them responsibly on the web. Like so.

Right now, srcset only allows us to describe images with their width, relative to their layout container (using either x descriptors or w descriptors + sizes). As other responsive image variables become important, it makes sense to be able to describe resources with them, too. h is probably the future-descriptor with the most consensus, but I also remember discussing type-based descriptors at some point, like:

srcset="i.jpg type(image/jpg), i.webp type(image/webp)"

Thinking ahead, at some point, it might make sense to add color-gamut, too:

<img srcset="i-p3.jpg gamut(p3)" src="i-srgb.jpg" alt />

This pattern, compared to the status quo…

<picture>
<source media="(color-gamut: p3)" srcset="i-p3.jpg" />
<img src="i-srgb.jpg" alt />
</picture>

…would provide some of the same advantages that w+sizes does over <source media="(min-width)">: less and less-complicated markup (although the combinatorics of, say, just 3 sizes × 2 formats × 2 gamuts = 12 resources for one image, still get a bit dizzying*), and putting control in the hands of the (more context-aware, less error-prone) browser.

*: this is a strong argument for adding a Gamut (or whatever) hint to Client Hints, too, to take the responsibility for this complexity away from markup / authors, and put it on the server.

Sorry, to me this seems to aimed at an edge case of an edge case.

Separate images in the example on WebKit blog are probably meant to show what can be done, rather than what should be done.

In my experience, wide-gamut images can be used on all displays, without any extra markup.

• Penalty in file size is not as large as it was for high-DPI images.

• The difference between sRGB and P3 gamuts is not that large to require a separate image. It’s smaller than differences between different lighting conditions (outdoors/day/night) and similar to variations between existing "sRGB"ish displays.

• Image formats support “rendering intent” setting which covers multiple use-cases without a need to manually provide re-colored images. Even if you want to have an image with “very red” and “very very red”, you can disable colorspace clipping and have that contrast preserved in sRGB.

And the selection already works with <picture> for edge cases when that would be needed, but I’m really struggling to imagine a case that isn’t covered by automatic colorspace conversion.

So all it does is provide microsyntax that saves some typing compared to <picture>, at the same time muddying the distinction between always-respected media queries of <picture> and choose-whatever-you-like nature of srcset.

In my experience, wide-gamut images can be used on all displays, without any extra markup. [snip] …I’m really struggling to imagine a case that isn’t covered by automatic colorspace conversion.

The problem is browsers that don’t color manage. P3-encoded images in unmanaged, sRGB environments look bad: noticeably desaturated. The biggest culprit right now for that is Chrome on Android, but it looks like that’s about to change.

I think you’re right that advocating for color management in browsers – and using the <picture> pattern when you really need it – is probably the best way forward (rather than adding profile descriptors to srcset).

• Penalty in file size is not as large as it was for high-DPI images.

There is no bandwidth cost to encoding your images in a wider space. There is a significant bandwidth cost to encoding them at deeper depths (e.g. 12-bit, or 16-bit colors, vs 8). Luckily (?) JPEG is limited to 8 bits, so we’re stuck with that for a while (and if your image doesn’t have extremely smooth gradients, it’s hard to see any banding artifacts w/ P3. ProPhoto and Rec2020 might be another story).