A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
Field tip: for choosing the right html element, test both the ordinary path and the first case that makes your assumptions false.
Source-reading note: the exact semantics here come from the HTML element/attribute you chose, not its CSS appearance.
When this goes wrong, the browser usually keeps rendering. That is what makes the bug easy to miss: recovery can hide a broken source document. In this lesson, the focus is decision-making between similar elements based on meaning and behavior. 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.
<button type="button">Open filters</button><a href="/filters">Filters</a>
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.
<!-- Contrast the weak version --><div>Choosing the Right HTML Element used as a generic container</div>
The browser's defaults are part of the behavior you are learning. Prefer native semantics first, then test the exact combination of attributes and content you plan to ship.
<section aria-labelledby="topic-title"><h2 id="topic-title">Choosing the Right HTML Element</h2><p>Use the element that matches the content's meaning.</p></section>
In a team codebase, the expensive bugs usually come from assumptions. Someone assumes an anchor is just a button with a different visual style, that a placeholder is a label, that an iframe is only a rectangle, or that a client-side constraint is security. The safe engineering move is to name the browser behavior you actually depend on and encode it directly in HTML.
The practical test is simple: remove the CSS, resize the viewport, and try the page with a keyboard. The structure should still make sense.
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.