Repository navigation
Responsive images: should we define source selection normatively instead of leaving it implementation-defined #13077
Description
What is the issue with the HTML Standard?
All three engines implement the same rule:
- sort by density
- pick the first candidate whose density ≥ the device pixel ratio (including page zoom)
- if none, pick the last.
There is one blink-related optimization to prefer an already-loaded higher-density candidate, but it's an interop issue and rarely used.
The implementation-defined facade is costly:
- It's untestable. WPT can only test de-duplication (select-an-image-source.html); nothing can assert currentSrc for w/x selection. The behaviour is universal but unenforced.
- Authors already rely on the exact rule. Every workaround in Authors have no way to ask for a higher or lower pixel density than the browser's default when selecting from
srcset#13069 (inflated w descriptors, sizes lies, optimumx-style libraries) only works because "first ≥ DPR" is universal. The spec says they can't depend on it; the ecosystem does. - New work needs a defined baseline. Authors have no way to ask for a higher or lower pixel density than the browser's default when selecting from
srcset#13069 proposes a multiplier/priority on the selected density; naturalWidth-from-density (Makesizesdetermine the natural width ofimg#13046, No way to read an image's true intrinsic dimensions when sizes="auto" (or any w-descriptor srcset) is used #12565) exposes the choice to script; the sizes=auto reselection loop (sizes=auto images shouldn't use concrete object width to select source #12248) needs a known selection function to reason about stability. A multiplier on an undefined choice is undefined.
Proposing to cement the existing behavior. If UAs want to do something different in the future, we can review whether implementation-defined behavior would be web compatible.
Note CSS is in the same state — css-images-4 says image-set() lets "the UA decide which is most appropriate". Blink unified the two in 2024; defining one gives the CSSWG something to reference.
Activity
eeeps commentedon Oct 14, 2026
One more datapoint to inform this decision that I just remembered, about whether and how UAs use the flexibility the spec currently offers them... when
devicePixelRatiowas >1, Chrome used to pick the closest resource (by geometric mean) to the density target, rather than the smallest one that was larger. So when offered a 1.9x resource and a 3x resource when trying to hit a 2x target, Chrome would pick the 1.9x, while Safari and Firefox would pick the 3x.I just tested and this no longer seems to be the case, but I'm pretty sure it was the last time I looked, in 2024.
When did this change, and why? Presumably interop?
noamr commentedon Oct 14, 2026
This would be chromium/chromium@c1e91d248c.
Yea, the ratio of complexity cost vs. measurable value for browsers to maintain this kind of divergence wasn't worth it.