Web Standards Behind LWC: Web Components and Shadow DOM
By the end of this lesson, you'll be able to:
- Name the four core Web Components browser APIs LWC is built on
- Explain what the Shadow DOM is and why LWC uses it
- Predict how Shadow DOM affects CSS and DOM queries across components
Prerequisites: "LWC vs. Aura Components"
The Four Pillars of Web Components
- Custom Elements — lets you define new HTML tags, like
<c-my-component>. - Shadow DOM — style and DOM encapsulation, covered in depth below.
- HTML Templates — the
<template>tag: inert, reusable markup that's only parsed when explicitly used. - ES Modules — native JavaScript's own
import/exportsystem, no bundler-specific magic required.
LWC layers Salesforce-specific tooling — decorators, the wire service, base components — on top of these four standards. It doesn't replace them; it builds on them.
What Is the Shadow DOM, and Why Does It Matter?
On a normal webpage, CSS and DOM queries are global — a style rule written anywhere can affect any element anywhere on the page. Shadow DOM creates an encapsulated boundary around a component: its internal markup and styles are isolated from the rest of the page, and vice versa. Your component's CSS can't accidentally leak out and break someone else's component, and outside CSS can't accidentally reach in and override yours.
This matters enormously in Salesforce specifically, where many components from many different sources — Salesforce's own base components, your custom LWCs, possibly AppExchange package components — all render on the very same page at once.
How This Plays Out in Practice
// From OUTSIDE a component (e.g. the browser console, or a parent
// component's own code), this will NOT find elements rendered
// inside another component's shadow boundary:
document.querySelector('.some-class-inside-a-component');
// returns null — the shadow boundary blocks it.To interact with a component from outside, you go through its deliberately-exposed public API (its @api properties and methods) instead of reaching into its internals — full detail in Module 5.
Why This Matters in Real Projects
Shadow DOM prevents an entire category of bug: "why did installing this AppExchange package break the styling on my custom page?" It makes components genuinely reusable and composable without requiring careful naming coordination between every team that ever builds a component for the org. It's also part of why LWC performs well — browsers optimize natively for this pattern, rather than Salesforce having to reimplement isolation in JavaScript on top.
Exercise
Explain, as a comment, why two completely different LWC components can both safely use a CSS class named .title without any conflict.
Show hint
Think about what the Shadow DOM boundary actually isolates.
Exercise
Challenge: a teammate asks you to write CSS in ComponentA that changes the background color of a <div> living inside a child ComponentB. Explain why a plain CSS selector won't work, without needing to write the full solution.
Show hint
Recall what Shadow DOM blocks from outside a component.
Web Standards Behind LWC: Web Components and Shadow DOM Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
LWC layers Salesforce-specific tooling on top of four native browser standards — and Shadow DOM, the encapsulation piece, is the reason many components from different sources can safely coexist on the same Salesforce page.