Choose Style Encapsulation on Purpose In short: is right for essentially every component in a library. is for genuine isolation from a hostile page. is almost never the answer, and it is not the answer for modals. Angular gives you three encapsulation modes. Most developers never change the default, which is usually correct — but "correct by accident" stops being good enough when you are shipping components to twenty applications. Emulated — the default Angular generates a unique attribute per component, adds it to the elements in that component's template, and rewrites the component's CSS selectors to require it. Conceptually, you write: and Angular emits something equivalent to: The host element gets its own attribute, which is what compiles against. The exact attribute names are an implementation detail — never write them yourself, and never target them in a test. What it guarantees, and what it does not It does: stop your component's styles from leaking out to the rest of the page. It does not: stop the outside world from styling your elements. Angular's documentation says so directly — global styles defined outside a component may still affect elements inside a component with emulated encapsulation. A global rule reaches straight into your card, which is exactly leak one from lesson one, and why class prefixes matter. Angular is also careful to say that in both and it does not guarantee your component's styles will always win a collision with outside styles. Encapsulation is scoping, not a priority system. and Setting on is worth doing deliberately. A custom element defaults to , which quietly breaks margins, heights, and flex behaviour. ShadowDom — native isolation Angular attaches a real shadow root and renders your template and styles inside it. What you gain: genuine, browser-enforced isolation in both directions. Outside CSS cannot reach in. Your styles cannot get out. What you pay: Global stylesheets do not apply inside — including CSS resets and any utility classes. Everything the component needs must be in its own stylesheet. Event retargeting changes how some events appear to listeners outside the shadow root. Content projection uses native , which behaves differently from in edge cases. Some third-party libraries that query the document cannot find your elements. Important: CSS custom properties do cross the boundary. They are inherited properties, and inheritance passes through a shadow root normally. This is precisely why custom properties became the standard theming channel for web components. So your entire tier-three token API keeps working inside a component. If you have read that custom properties do not pierce shadow DOM, that is backwards — and the mistake matters, because it would push you toward abandoning the token system for exactly the components that need it most. None — no encapsulation Styles are injected globally, unscoped. Every selector in that component's stylesheet becomes a global rule. Write and you have just changed every in the application. There is one honest use: a component whose job is to publish global CSS — a token bundle, a reset, or a set of overlay panel classes. Even then, scope every selector by hand: Choosing Component Mode Why --- --- --- Buttons, cards, badges, inputs, steppers Scoped, tokens work, global resets apply A widget embedded in a page you do not control You need protection from a hostile stylesheet A third-party embed or self-contained report Isolation is the point Dialogs, overlays, toasts See below A stylesheet-publishing component Its purpose is global CSS Why dialogs are not a case for This is the recommendation that most often appears in styling guides, including an earlier version of this course, and it is wrong. The reasoning goes: a CDK dialog renders into at the end of , outside the component that opened it. So the dialog's own styles will not apply, so you need . The premise is right, the conclusion is not. The dialog component is still a component , and Angular applies its encapsulation attributes to its own template wherever that template is rendered. A dialog with encapsulation styles itself perfectly well inside the overlay container. What genuinely lives outside the component is the overlay chrome — the backdrop and the panel wrapper, which the CDK creates and which you target via and . Those are global classes by nature. Put them in your global stylesheet: Two global classes, and the dialog component keeps its encapsulation. Reaching for on the dialog itself buys nothing and disables scoping on everything else in it. "But I thought was the more modern, correct choice" This is an appealing argument. is a polyfill-flavoured workaround with generated attributes; is the platform feature that was designed for exactly this. Standards beat emulation. Why would you not use the real thing? Because in a design system, near-total isolation is a cost, not a feature. The whole point of a component platform is that components participate in…