openskills.info
Course catalog
Course Preview

Web Components

Web Components are browser standards for creating reusable HTML elements with their own behavior, structure, and styling boundaries. They let a component work in ordinary HTML and across application frameworks.

itWeb development

Don't Panic — Web Components

Web Components are a set of browser standards for creating reusable HTML elements. Not a framework, not a library—actual browser APIs that let you define a custom tag, give it a lifecycle, and optionally hide its internals behind a shadow boundary. If you've ever wished you could invent <status-badge> and have it just work, this is the spec that makes that possible.

The concept you need to hold in your head: every web component is a host element sitting in the page's ordinary document tree, which is also called the light DOM. That host can attach a shadow root, creating an internal tree with its own style scope. Children of the host can be placed into named positions inside that tree through slots. That's it—two trees, one boundary, and a composition model that decides what renders where.

The four pieces are custom elements (bind a hyphenated tag to a class), shadow DOM (encapsulate internal DOM and styles), templates (store inert content for cloning), and slots (let callers inject content into specific positions). You don't have to use all four. A custom element without shadow DOM is perfectly valid. A shadow root without a custom element is possible too. Pick each piece for the boundary it creates.

Here's the part that surprises most people: shadow DOM is not a security boundary. It prevents your page's CSS from accidentally bleeding into a component and vice versa, which is genuinely useful. But any page script can reach into an open shadow root and poke at its internals. Closed mode hides the shadowRoot property, but it doesn't stop direct DOM interaction. If you need to sandbox untrusted code, you want an iframe, not a shadow root.

The real difficulty with web components isn't the API—it's accessibility. ARIA attributes that reference other elements by ID, like aria-labelledby or aria-describedby, break silently at shadow boundaries because IDs are scoped to their shadow root. A label inside one component cannot reach a description living in another. The platform's answer is ElementInternals, which lets a custom element set default accessibility semantics that yield to explicit consumer overrides. But wiring it up correctly—especially for cross-component references—takes deliberate work that the spec does not do for you.

Before reaching for a custom element, ask whether native HTML already solves the problem. A styled <button> or <select> comes with keyboard handling, focus management, form integration, and accessibility semantics that a custom implementation would need to reproduce and test. The cost of a web component isn't registration—it's the API surface you now have to design, document, version, and test in real browsers.

Start with the Debugging tab for a methodical order: confirm the module loaded, check the registry, verify the lifecycle, then inspect the shadow tree. The Landscape tab shows which libraries reduce boilerplate without replacing the browser's component model. The Timeline tracks how the standard evolved from early W3C drafts to cross-browser support with server-rendering and scoped registries.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources