Resolution via EXIF erases the caching advantages of Width being defined in terms of device pixels

[eeeps]

Width used to be defined in terms of CSS pixels. This was changed in order to help cacheability; the idea being, that the same, cached, 1000-pixel-wide resource could be used to satisfy, e.g., both 500px@2x 1000px@1x requests.

This made sense in a world where resolution was communicated from servers to user agents via the Content-DPR header. It doesn't make sense in a world where resolution is baked into the image resource itself, via EXIF information. Even though the image pixel data may the same for 500px@2x and 1000px@1x responses, the files are not, because their EXIF resolution metadata differs.

In light of this erased benefit and the costs raised in #3, I'm wondering if we should deprecate Width and mint a new Layout-Width hint?

[simonhearne]

This issue extends further than EXIF. Automatic image optimisation services like Cloudinary and Akamai Image Manager can use DPR and Width hints to deliver the correct resolution image. When combined with <img srcset> this can result in doubling up on DPR, as the browser selects an image based on intrinsic size, e.g. image.jpg?width=[intrinsicPx]. If Width and DPR hints are opted-in, the request would also include Width: [intrinsicPx] / DPR: [dpr]. The logical response to this request would be an image of [intrinsicPx] * [dpr]px wide. The outcome of this is dpr^2 - significantly over-delivering the image.

IMO Width should be CSS pixels not intrinsic, but changing the spec would be difficult. I agree that a Layout-Width hint is a good enhancement to the spec. Caches could then still be keyed on Width to resolve the concerns raised in igrigorik/http-client-hints#61

[eeeps]

When combined with this can result in doubling up on DPR

In general, a lot of trouble can be avoided by not trying to use srcset and Client Hints at the same time; perhaps this should be noted more in the spec.

IMO Width should be CSS pixels not intrinsic, but changing the spec would be difficult. I agree that a Layout-Width hint is a good enhancement to the spec

Where I'm at with this, after some thought:

• Width ÷ DPR = Layout-Width
• A server only needs two out of three to scale and set the resolution on a response, the third can be calculated
• For computers, any two will do
• There are complexity/confusion costs to offering all three hints, and multiple ways to convey the same information
• Width is an integer, DPR would ideally be a rational; Layout-Width probably should be a rational, too. Structured headers don't have a rational type so DPR is currently specified as a decimal; for both it and a potential Layout-Width hint, small rounding inconsistencies seem likely. (See: sf-decimal doesn't have enough precision to convey all possible DPR values #17)
• For people, the ergonomics of which two are easier to deal with are dependent on use case and mental model; I had my own initial model/bias (Layout-Width * DPR), but upon further reflection and experimentation, I'm not sure if any use case or mental model can be said to be dominant.
• Width is a slightly unfortunate name; there are multiple "widths" at play. I'm not sure how to make it more specific without making it either unwieldy or obscure, though (Device-Pixel-Width? DPW?)
• If a server/system doesn't care about intrinsic densities/dimensions (so: it can always count on the image being extrinsically sized for layout) and doesn't want to vary compression characteristics by density, it can run on Width alone, and reap a lot of caching benefits. I'll flesh this idea out a bit more in Servers can't set resolution on images requested with only Sec-CH-Width #3.

All of this (plus inertia) is making me lean towards not changing anything.