An HTML `<video>` has three `<source>` children in different formats. Explain how the browser picks one, what the `type` attribute contributes, and when the content between the `<video>` tags is displayed.

## The selection algorithm, informally ```html <video controls width="1280" height="720" poster="frame.jpg"> <source src="clip.webm" type="video/webm"> <source src="clip.mp4" type="video/mp4"> <p>Your browser does not support the video element. <a href="clip.mp4">Download the clip</a>.</p> </video> ``` The browser takes the `<source>` children in document order. For each one it asks: do I support this type? If the answer is a confident no, it moves on. If it is plausible, it fetches and attempts to use that resource, and — crucially — it does not go looking for a better one afterwards. **First playable wins.** That single fact determines how you order the list: preferred, most efficient format at the top, universal fallback at the bottom. ## What type actually buys you `type` holds the MIME type of the resource, and may carry the `codecs` parameter, which pins the actual encoder profiles inside the container: ```html <source src="clip.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'> ``` This matters because a container is not a codec. `video/mp4` may hold H.264, HEVC or AV1, and a browser that supports the container may not support what is inside it. With the parameter present the browser can reject a candidate immediately, on a string comparison, with zero network traffic. Without `type` at all it may have to open the resource to discover it cannot use it — wasted bytes and a slower start on exactly the devices that can least afford it. Note the quoting: because the codecs value itself contains double quotes, the attribute is written with single quotes around it. ## src on the element beats source children If the `<video>` element carries its own `src`, the resource selection algorithm uses it and the `<source>` children are ignored entirely. This is a real bug in the wild: someone adds a `src` for a quick test, leaves it in, and the carefully curated fallback list becomes dead markup. Use one style or the other, never both. ## What the fallback content is (and is not) The flow content between `<video>` and `</video>` is shown by user agents that **do not implement the element**. A browser that understands `<video>` renders the element and never displays that content, even when every single `<source>` fails to load or decode. So the paragraph reading "your browser cannot play this video" is, in practice, seen by almost nobody — and it is the wrong place to put your handling for a codec failure. What does happen on failure: each `<source>` that cannot be used fires an `error` event at that `<source>` element. That is the hook a player would use to detect exhaustion of the candidate list and show its own message. It is worth still writing useful fallback content — a download link is friendlier than a sentence about browsers — but do not budget for anyone seeing it. ## Ordering strategy in practice Modern codecs are smaller for the same quality but not universally supported; H.264 in MP4 remains the near-universal floor. So the standard shape is newest first, floor last: ```html <video controls width="1280" height="720" poster="frame.jpg"> <source src="clip.webm" type="video/webm"> <source src="clip.mp4" type="video/mp4"> </video> ``` Invert those two lines and every browser that supports both takes the MP4 — the WebM encode you paid to produce is never requested. Reviewers should read `<source>` order as load-bearing, the same way they read any first-match fallback chain. ## Details that trip people up - `<source>` is a void element: no closing tag, no children. - The same mechanism applies to `<audio>`, with types like `audio/ogg` and `audio/mpeg`. - `<source>` elements must come before any `<track>` children and before the fallback content. - Listing four or five formats is usually waste. Two encodes — one modern, one universal — cover the field; every extra encode costs storage and build time for a shrinking slice of users. - A `<source>` with no `type` is legal, just less efficient; it is better than a *wrong* `type`, which will cause the browser to skip a file it could actually have played.