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 data-* attributes, DOM access, and the limit of custom metadata. 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.
Warning: invalid or overly permissive markup may still render. Rendering is not proof that the document model is correct.
Step by step
3 steps to follow
<button data-product-id="42">Add</button><script>button.dataset.productId</script>
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.
<meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1">
Don't confuse browser-side convenience with a security boundary. The markup in data attributes and custom metadata should improve behavior, but authoritative validation and policy belong at the trust boundary that processes the request.
<link rel="icon" href="/favicon.svg" type="image/svg+xml"><link rel="stylesheet" href="/styles.css"><script type="module" src="/app.js"></script>
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.
A small, explicit HTML decision now is usually cheaper than a compatibility or accessibility workaround later.
Implementation note: Store small application-facing values in data attributes without inventing nonstandard semantics. Keep the browser behavior observable while you work.
Checkpoint: you can now connect the markup for data attributes and custom metadata to a browser behavior and a concrete debugging step.
Checkpoint: you can now connect the markup for data attributes and custom metadata to a browser behavior and a concrete debugging step.
Finish the lesson once you have worked through the material. This awards ★ 20 XP.