The design was reasonable. A summary card, used all over the product, and a new collapsible sidebar with a dark surface. Inside that sidebar the card needed a lighter border and a slightly raised background, because on a dark panel our normal card read as a hole rather than a surface.
I opened the card component, added dark = input(false), and went looking for the place that would set it. That's where the afternoon went.
The sidebar didn't render the card. The sidebar rendered a nav section, which rendered a widget list, which rendered the card. So making the card aware of the dark surface meant adding a dark input to the nav section and the widget list too, and having each one pass it along — three components changed, two of which have nothing to do with theming and never will. A widget list arranges widgets. Teaching it the word "dark" so it can hand the word to something else is how a component acquires responsibilities that aren't its own.
I stopped at the second file. When a prop has to travel through components that don't use it, the prop is usually the wrong mechanism.
The information was already in the DOM
What I'd missed is that nothing was actually unknown here. The card didn't need to be told it was in a dark region — it was, physically, inside an element that already said so. The sidebar had class="theme-dark" on it from the day it was built. The fact was sitting three levels up the tree, and I was writing plumbing to deliver a copy of it downward.
CSS has read upward for its entire existence; that's what the cascade and descendant selectors are. The wrinkle in a component framework is encapsulation — the card's stylesheet is scoped to the card, so it can't just write .theme-dark .card. That rule would need to match an element outside the component's own scope, which is exactly what emulated encapsulation prevents.
:host is the first half of the answer. It selects the component's own host element from inside the component's stylesheet, which is how you style the box you occupy rather than the contents you render. :host-context() is the half I'd underused: it applies when any ancestor of the host matches the selector you give it. Not the parent specifically — anywhere up the tree.
So the card asks the question itself:
:host {
background: var(--surface);
border: 1px solid var(--border);
}
:host-context(.theme-dark) {
background: #1c2430;
border-color: #5b6a7d;
color: #f2f5f8;
}Nothing changes at the call site. This is the same markup the sidebar already had, with no new bindings anywhere in the chain:
<aside class="theme-dark">
<app-nav-section>
<app-widget-list>
<app-summary-card />
</app-widget-list>
</app-nav-section>
</aside>The card renders with the dark treatment inside that sidebar and with its normal treatment everywhere else, and the two intermediate components stayed exactly as they were. Zero inputs, zero JavaScript, zero knowledge of theming in components whose job is layout. The card became responsible for its own appearance in context — which is, if you say it out loud, obviously where that responsibility belonged.
One caveat that belongs in the same breath, because it surprised me when I checked. The native :host-context() pseudo-class is deprecated, and browser support for it was never universal — so if you're writing this in a plain web component with real shadow DOM, verify it before you rely on it. Angular's situation is different, and better: the compiler transforms :host-context() at build time into attribute-based selectors, so it doesn't depend on the browser implementing the pseudo-class at all. Angular's own styling guide is explicit that it provides full support for it. The tradeoff of that transformation is that it isn't governed by native pseudo-class rules at runtime, which is worth knowing before you reason too finely about its specificity. Under Angular's default emulated encapsulation, this is a supported, compiler-backed selector. Outside Angular, check first.
Value or context — that's the question that picks the tool
Threading an input through the tree is the version I abandoned, and I want to be fair to it, because there are cases where it's right. If the difference were behavioral — the card renders fewer actions in a compact rail, say — that's a real prop, and a prop should carry it. What made it wrong here is that the information was purely presentational and already present in the DOM, so the input was a second, manually maintained copy of a fact the browser could see. Two copies of a fact drift. Miss one hand-off in a new wrapper component and you get a light card on a dark panel with no error anywhere to explain it.
A theme service is the option I'd have reached for a few years ago, and it's genuinely the right answer for a user-selected theme — a preference read from storage, applied at the root, persisted across sessions. But this isn't a user preference. It's a regional fact about one part of the layout, and answering it with a service means components subscribing to state, styles that depend on JavaScript having run, and a service that has to somehow know which region each component sits in. That last part is the tell: the service would need to reconstruct the tree position that the DOM already encodes.
The comparison that actually matters is the one between :host-context() and inherited custom properties, because both read from the surroundings and both avoid the prop-threading problem. The distinction I've settled on is simple enough to use under pressure. When the difference is a value — a color, a spacing, a radius — use a custom property. The ancestor sets --surface, the card reads var(--surface), and the card doesn't even learn that a theme exists. That's the more composable of the two, it scales to any number of contexts without touching the component again, and it's my default for design-system work.
Use :host-context() when the difference is the presence of a context rather than a value — when being in a dark region changes which rules apply, not just what a token resolves to. That's the case here, honestly: inside the sidebar the card gains a border it doesn't otherwise have and drops its shadow. You can force that into tokens by inventing --card-border-width and --card-shadow and setting them to the values that mean "off," but you're then encoding a structural difference as a pile of neutralized values, and the reader has to reverse-engineer the intent from six overrides. A single :host-context(.theme-dark) block states it.
The lesson isn't that one beats the other. It's that both are better than an input, and the question that separates them is whether you're changing a value or answering a question about where you are.
Some Facts Belong to the Surroundings
The instinct to pass everything down as props comes from a good place — explicit data flow is easier to trace, and I still want it for behavior and content. But it treats the component tree as though the only legitimate channel is the one you built by hand, and the DOM is not a black box the framework hands you. A component that reads its own context is less coupled than one that has to be told, because the telling requires every component in between to participate in a concern none of them own. Ask what the difference really is: a value the surroundings can supply, or a question the component can answer about where it's standing. Get that right and the components in the middle go back to doing their own jobs — which is the only reliable sign that a boundary was drawn in the right place.
