A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
In production, this piece of HTML is rarely isolated; it sits between content, navigation, user input, and browser defaults. In this lesson, the focus is audio/video sources, controls, poster frames, and fallback content. That matters because HTML is interpreted by a parser and then exposed to browser features such as navigation, accessibility tooling, form controls, media handling, and script APIs. A correct-looking screenshot can still hide a poor document model.
<video controls poster="poster.jpg" width="800"><source src="demo.mp4" type="video/mp4"></video>
Start with the smallest meaningful example. The working snippet demonstrates the core syntax, but the important part is what each piece contributes: the element supplies semantics or behavior, attributes refine that meaning, and surrounding structure gives the browser context. Don't add markup just because a framework or copied example happens to include it.
Source-reading note: the exact semantics here come from the HTML element/attribute you chose, not its CSS appearance.
Don't confuse browser-side convenience with a security boundary. The markup in audio and video elements should improve behavior, but authoritative validation and policy belong at the trust boundary that processes the request.
<video controls autoplay><source src="intro.mp4" type="video/mp4"></video>
Now put the same idea under pressure. A realistic failure is: Configure media for playback, user control, and a sensible fallback path. The browser may recover, ignore an invalid combination, or leave the user with a control that appears visually fine but behaves differently than expected. That is why source inspection and keyboard testing belong in the workflow.
<video controls preload="metadata"><source src="intro.webm" type="video/webm"><source src="intro.mp4" type="video/mp4"><track kind="captions" src="en.vtt" srclang="en" label="English"></video>
For this topic, the edge case is worth remembering: HTML has legacy parsing and compatibility behavior, so invalid markup does not always fail loudly. If you are debugging a strange result, reduce the page to one element at a time, validate the source, and inspect the resulting DOM. Small reproductions beat guessing at the full application.
The practical test is simple: remove the CSS, resize the viewport, and try the page with a keyboard. The structure should still make sense.
Field tip: for audio and video elements, test both the ordinary path and the first case that makes your assumptions false.
Engineering judgment: prefer the native HTML behavior described here before reaching for a custom widget.
Finish the lesson once you have worked through the material. This awards ★ 20 XP.