No way to read an image's true intrinsic dimensions when sizes="auto" (or any w-descriptor srcset) is used

[austinh]

What is the issue with the HTML Standard?

No way to read an image's true intrinsic dimensions when sizes="auto" (or any w-descriptor srcset) is used

Summary

When an <img loading="lazy" sizes="auto"> uses a srcset with w descriptors, naturalWidth/naturalHeight always equal the element's layout/container width, not the resource's true intrinsic dimensions. Because naturalWidth returns the density-corrected natural width and the selected source's density is computed as descriptor / resolved-sizes, and sizes="auto" resolves sizes to the rendered width, the result is tautological: naturalWidth === containerWidth, for every image, regardless of the file's real pixel size.

This isn't a browser bug - it's the specified composition of two behaviors - but it leaves authors with no reliable API to recover an image's true intrinsic dimensions once w descriptors are involved, and sizes="auto" makes the gap unavoidable.

Reproduction

JSFiddle: https://jsfiddle.net/ns58rcub/5/

Reproduced in Chrome 149 (macOS). The math generalizes: a 400px container yields naturalWidth 400 (800w ÷ 400 = 2× density → 800/2 = 400).

Why this is a problem

Common use cases need the real intrinsic size — computing aspect ratio, deciding whether to upscale, lightbox/zoom logic, analytics on served resolution. With sizes="auto", all of these silently get the container size and break.

Possible directions

1. An accessor that exposes the un-corrected intrinsic dimensions of currentSrc (raw file pixels).
2. Expose the resolved source size (cf. proposed currentSizes in Getting the current source size value of an img #6532) so authors can reverse the density correction themselves.
3. At minimum, a spec note documenting that naturalWidth/naturalHeight are tautological under sizes="auto".

Related: #6532 (requesting access to the computed source size value) — same root cause.