A page uses an HTML <picture> with several art-directed <source> elements, and the narrow mobile crop keeps appearing on wide desktop screens. Given how the browser selects a source, what are the likely causes?

## Reason from the algorithm, not from the markup Every bug in this area dissolves once you hold the selection rule precisely: walk the `<source>` children **in document order**; for each, if it declares `media` the query must match, and if it declares `type` the browser must be able to decode it; take the **first** that passes and resolve its `srcset`; if none pass, use the `<img>`. There is no scoring, no specificity, no "best match" — just the first hit. That single rule generates the whole differential diagnosis. ## Cause 1: a shadowing source above the one you wanted The classic form: ```html <picture> <source srcset="square.jpg"> <!-- no media: always matches --> <source media="(min-width: 900px)" srcset="wide.jpg"> <!-- never reached --> <img src="square.jpg" alt="Ada at the analytical engine"> </picture> ``` A `<source>` with no `media` and no `type` matches unconditionally, so everything after it is unreachable. The same thing happens with a condition that is merely too broad — `(min-width: 320px)` above `(min-width: 900px)` is true on every desktop, so the walk stops on the first line. The fix is to treat the source list as an ordered decision table: narrowest, most specific condition first, broadening downward, with the unconditional candidate on the `<img>` where it belongs. People who carry over CSS instincts author it in ascending mobile-first order and get the inverse of what they intended, because in markup **earlier wins** while in the cascade **later wins**. ## Cause 2: the desktop source never matches If the intended source cannot match, the walk falls through to the `<img>` — which usually holds the small crop, so the symptom is identical to shadowing. Things that make a source unmatchable: - **A malformed media query.** An invalid query never matches; there is no error and nothing in the console. - **`src` instead of `srcset`.** Inside `<picture>`, `<source>` uses `srcset`. `src` is the `<video>`/`<audio>` spelling and is inert here, so the source is effectively empty. - **A `type` the browser cannot decode**, when the desktop crop was only ever offered as AVIF and the fallback JPEG line for that crop is missing. That is the combined-axis bug: with both `media` and `type` in play, each crop group needs an entry with no `type` so the crop survives when the format does not. - **A `min-width` threshold above any real viewport**, often after a units mistake. ## Cause 3: what the media query is measured against `media` on `<source>` is evaluated as a media query against the viewport and device — the same context a stylesheet media query sees. It is **not** measured against the element's container or the space the image will occupy after layout. If the image sits in a narrow sidebar on a wide page, `(min-width: 900px)` is true and the wide crop is selected even though the slot is 300 px. Teams who reason about the image's own box rather than the viewport ship exactly this bug. The corollary is a structural one worth stating in an interview: the breakpoints inside `media` attributes are a *second copy* of your layout breakpoints. Nothing keeps the two in sync, so a stylesheet refactor that moves the desktop breakpoint from 900 px to 1024 px silently opens a 124 px band where the layout is desktop and the crop is mobile. That is why these values should be emitted from one source by a component or build step rather than typed per page. ## Confirming rather than guessing Diagnose empirically. The `<img>` is the element that renders, so inspect it and read which file it actually resolved — devtools expose the current source on the image element — and check the network panel for which variant was requested. That distinguishes cause 1 and 2 (a source matched, but the wrong one, versus nothing matched) in seconds, whereas reading the markup invites you to see the intent instead of the behaviour. Also check at real viewport widths, not by resizing a window past a breakpoint and assuming a swap. Verify a fresh load at the target width. ## The one-line answer "First match wins in document order, so either something above it matched first or the desktop source could not match at all — and if nothing matches you get the `<img>`, which is usually the small crop, so those two failures look the same on screen."