Why does an <img> with a w-descriptor srcset need a sizes attribute at all, rather than the browser simply measuring how wide the element ends up being?

## The timing problem The interesting part of `srcset` is not the syntax, it is *when* the decision happens. When a browser receives HTML it does two things at once. The parser builds the DOM, and a lightweight **preload scanner** runs ahead of it looking for things worth fetching now — scripts, stylesheets, images. Image requests therefore start almost as soon as the `<img>` tag's bytes arrive. At that instant: - the stylesheet that sizes the image may still be in flight; - no box has been laid out; - the containing column's width is unknown. Waiting for layout before requesting the image would mean serialising the whole critical path behind CSS, which is exactly what the preload scanner exists to avoid. So the browser asks the author instead. `sizes` is the author's declaration of how wide this image is going to be. ## What sizes may contain, and why ```html sizes="(min-width: 1200px) 600px, (min-width: 640px) calc(50vw - 2rem), 100vw" ``` Each entry is a media condition plus a length; the last entry is a bare length used when nothing else matched. Evaluation is **first match wins**, so order the conditions from most specific to least, and always end with an unconditional fallback. The permitted lengths are absolute or viewport-relative units — `px`, `em`, `rem`, `vw`, `calc()` combinations of them. **Percentages are not allowed.** That restriction follows directly from the timing: a percentage means "of the containing block", and there is no laid-out containing block yet. Everything `sizes` can express is computable from the viewport and font sizes alone. Media conditions here are also viewport-scoped for the same reason: `(min-width: 900px)` refers to the viewport, never to the element's own box. ## The default when you omit sizes Omitting `sizes` while using w descriptors does not disable selection; the browser falls back to a source size of `100vw`. That default is right for a full-bleed hero and wrong for almost everything else. A thumbnail in a card grid rendered 280 CSS pixels wide, with `sizes` omitted on a 1440-pixel viewport, will be treated as if it needed 1440 pixels — and on a 2x screen, 2880. The image looks perfect and costs an order of magnitude more bytes than it should. Nothing warns you. ## Why this duplicates your CSS, and what to do about it The uncomfortable truth of `sizes` is that it restates, in a second syntax, a layout fact that already lives in your stylesheet. Change the grid from three columns to four, or add a max-width to the article body, and the `sizes` attribute is now lying. Nothing breaks visually — the browser simply requests the wrong candidate forever. Practical mitigations: - Derive `sizes` from the same tokens the layout uses (breakpoints, gutters, container max-width) rather than eyeballing it. - Emit it from a component, so one image partial owns the value for every instance of that layout slot. - Keep it slightly conservative rather than optimistic: a `sizes` that under-states the width yields a visibly soft image, which is worse than a mild over-fetch. ## Verifying it The value that matters is the *effective* one after media conditions are evaluated at the current viewport. Two checks: ```js // the URL the browser actually settled on document.querySelector('img').currentSrc; ``` and the network panel, which shows which candidate was requested and how many bytes it cost. Compare the requested file's width against the element's real rendered width times the device pixel ratio; a large gap means `sizes` is wrong. ## Where the model is changing The HTML standard has since added `sizes="auto"`, valid only on images that are also lazily loaded, which lets the browser use the element's real layout width instead of a promise — the lazy case being precisely the one where layout is already known by the time the fetch starts. Support is not yet universal, and the syntax is designed so that `auto` comes first with ordinary sizes entries after it as the fallback for browsers that do not implement it. For eagerly loaded images above the fold, the promise model still applies. ## The takeaway for an interview Say the timing sentence out loud: *the browser chooses a candidate before it knows the element's width, so `sizes` is a promise, not a measurement.* Everything else — the ban on percentages, the viewport-only media conditions, the `100vw` default, the drift risk — falls out of that one fact.