picture and Art Direction

## picture is a decision layer, not an image The most useful mental model for `<picture>` is that it renders nothing itself. It is a small container whose only job is to let the browser choose which *file* the `<img>` inside it will display. Everything about the image as a thing on the page — its accessible name, its intrinsic dimensions, its classes, its loading behaviour — belongs to the `<img>`. ```html <picture> <source type="image/avif" srcset="chart.avif"> <source type="image/webp" srcset="chart.webp"> <img src="chart.png" alt="Revenue rose from 2m to 9m between 2019 and 2024" width="800" height="450" class="report-figure" loading="lazy"> </picture> ``` The browser evaluates the `<source>` children in order, and if one matches it points the `<img>` at that file. The DOM element that ends up in the layout, in the accessibility tree, and in your stylesheet's reach is the `<img>` in every case. ## The last-child rule The content model of `<picture>` is: zero or more `<source>` elements, then exactly one `<img>`, last. This is not stylistic. Source selection is a first-match walk that stops when it reaches a match or runs out of sources, and the `<img>` is the terminal fallback in that walk. Putting the `<img>` first would mean the fallback is evaluated before the preferred candidates, which is exactly backwards. Omitting the `<img>` entirely is the failure mode people hit in practice, usually while refactoring. Nothing appears — not a broken-image icon, not the first source, nothing — because there is no image element to render and no `alt` text to expose. Assistive technology sees an empty container. ## Where each attribute goes **On the `<img>`:** `src` (the universal fallback file), `alt`, `width`, `height`, `class`, `id`, `loading`, `decoding`, `fetchpriority`, and its own `srcset`/`sizes` if you also want resolution switching in the fallback case. **On each `<source>`:** `srcset` (never `src` — that spelling belongs to `<source>` inside `<video>` and `<audio>`), plus optional `sizes`, `media`, `type`, `width` and `height`. **On `<picture>`:** essentially nothing image-specific. It takes global attributes, but there is no `alt`, no `src`, no `srcset` on the wrapper. The `alt` placement follows directly from the model: there is exactly one image being described, and which file was selected does not change what the image *means*. One `alt` on the `<img>` covers every candidate — which is also a design constraint worth noticing. If your desktop crop and your mobile crop convey materially different information, one `alt` string cannot honestly describe both, and that is a signal the art direction has gone too far. ## width and height on source A subtlety: when your art-directed crops have different aspect ratios, a single `width`/`height` pair on the `<img>` describes only the fallback. `<source>` accepts `width` and `height` for exactly this reason, so each candidate can declare its own intrinsic dimensions and the browser can reserve the right box before the bytes arrive. ## Styling and scripting reach the img Because the `<img>` is the rendered element, a CSS selector, a class, or a script that queries the image should target the `<img>`, not the `<picture>`. A common bug is attaching a class to `<picture>` and wondering why rules meant for the image do not apply the way they would on a bare `<img>` — the wrapper is a different element with its own default display behaviour. ## How to say it in an interview "`<picture>` and `<source>` decide *which file*; the `<img>` is the image. So the `<img>` is mandatory, it goes last, and every image attribute — starting with `alt` — lives on it." That single sentence covers the content model, the failure mode, and the accessibility consequence.