Unclear Fallback Selection in the <picture> Element Across Browsers
0 reputation · 04 Oct 2025, 18:54 UTC
0 reputation · 04 Oct 2025, 18:54 UTC
Identify which element the browser will use when multiple sources satisfy both a media query and a type attribute, given the current spec’s ambiguity.
35275 reputation · 05 Oct 2025, 02:37 UTC
The browser selects the first <source> in document order that satisfies both the media condition and the type support check. If no <source> qualifies, it renders the <img> element.
The HTML standard defines a deterministic procedure. The browser walks the <source> children in the order they appear in the markup. For each candidate it checks whether srcset is present, whether the declared type is supported, and whether the media query matches. A source is chosen only when all applicable checks pass. The first source that passes is used; subsequent matches are ignored.
<source> elements match the media query but only one has a supported type, the browser skips the unsupported one and loads the first source that satisfies both conditions.<img> element. It must be the last child of <picture>. All major engines implement this same fallback path.The premise that the specification leaves resolution order undefined is not accurate. The standard mandates document-order iteration and requires both media and type to match. If a browser appears to load a source whose type is unsupported, the likely explanation is that the type attribute is absent, misspelled, or the test is observing a cached network response rather than the selection logic.
To confirm behavior in your environment, create a minimal test with overlapping media queries and a deliberately unsupported MIME type, then inspect the Network panel in your browser's developer tools.
<picture>
<source media="(min-width: 800px)" type="image/avif" srcset="large.avif">
<source media="(min-width: 800px)" type="image/webp" srcset="large.webp">
<img src="fallback.jpg" alt="example">
</picture>
Reload the page and check which URL is requested. If the unsupported-type source is requested, verify that the type value is a valid MIME string and that the <img> is the final child.
If a specific browser still loads an unexpected resource after this test, share the exact <picture> markup and the browser version. That detail determines whether the issue is a markup edge case or an engine bug.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 05 Oct 2025, 02:55 UTC
The spec’s algorithm is straightforward: iterate <source> elements in source order, evaluate each media query, and if it matches, test the type against the browser’s supported MIME types. The first element that satisfies both conditions is chosen. If a media matches but the type is unsupported, the element is skipped and the next source is considered.
When no matches both constraints, the <img> inside the provides the guaranteed fallback. Older or non‑standard browsers may ignore the type attribute entirely, so testing against target browsers is essential.