In a component's shadow-root CSS, what can the `::slotted()` pseudo-element actually select, and why do so many attempts to style slotted content with it fail?

## Slotted nodes never leave the light DOM When a consumer writes `<my-card><p class="note">Hi</p></my-card>`, the `<p>` is a child of the host in the document tree. Slotting does not move it; the flattened tree just renders it at the slot's position. That single fact explains nearly every surprise here: the `<p>` is still a document-tree element, so document rules match it normally, and shadow-tree rules must use a special pseudo-element to reach it at all. ## What ::slotted() matches ```css /* inside the shadow root */ ::slotted(p) { margin: 0; } ::slotted(.note) { color: #555; } slot[name="header"]::slotted(*) { font-weight: 600; } ``` Three constraints: **Top level only.** It matches nodes *assigned* to the slot — the host's direct children with a matching `slot` attribute. Their descendants are unreachable. In `<my-card><p>Hi <em>there</em></p></my-card>`, `::slotted(p)` matches the paragraph and nothing in the shadow tree can select the `<em>`. **Compound selector only.** The argument is one compound selector: a tag, classes, attributes, pseudo-classes on the same element. `::slotted(div p)`, `::slotted(div > p)` and `::slotted(.a, .b)`-style structural nesting are not valid arguments (a selector list of compounds is allowed, combinators are not). Anything requiring a relationship between two elements is out. **No descending after it.** `::slotted(li) span` matches nothing, for the same reason as `::part()`: it is a pseudo-element. **Elements only.** Bare text assigned to a slot — `<my-card>Hello</my-card>` — is a text node, and `::slotted(*)` does not match it. Style it by styling the `slot` element itself, since the text inherits from where the slot sits. ## Why the page usually wins The subtler failure is a rule that *does* match but has no effect. Under the CSS scoping rules, when declarations from two different trees apply to the same element, **tree order decides before specificity**: for normal declarations, the outer tree wins. Slotted elements belong to the outer tree, so the consumer's plain `.note { color: black }` beats the shadow's `::slotted(.note) { color: red }` even though the shadow selector looks more specific. That is deliberate — the consumer authored that markup and should keep control of it — but it catches component authors who expected their shadow CSS to be authoritative. `!important` in the shadow tree reverses the order and wins, and is the right tool only for things that genuinely must not vary (a `display` value the layout depends on, for instance). ## Styling the slot instead A `<slot>` is a real element in the shadow tree and can be styled directly: ```css slot { display: block; padding: 8px; } ``` But a slot's default `display` is `contents`, so it generates no box of its own; setting `display: block` makes it a real box that wraps the assigned nodes, which changes layout and is sometimes what you want and sometimes a surprise. Inherited properties set on the slot *do* reach slotted content — the flattened tree parents the assigned nodes to the slot — so `slot { font-style: italic }` italicises them even though no `::slotted()` rule matched. That is often the cleanest way to influence slotted content: set inherited properties (and custom properties) on the slot or its shadow ancestors. ## What to do when ::slotted() is not enough - **Push values outward.** Declare custom properties on the slot's shadow ancestors; slotted content inherits them, and the consumer's own CSS can consume them with `var()`. - **Constrain by layout, not by selector.** Wrap the slot in a container you fully control and style that: padding, grid placement, max-width all work without touching consumer markup. - **Accept the ownership split.** The consumer authored those nodes; deep-styling them from inside would break the mental model that light DOM belongs to the page. `::slotted()` is best read as a way to set *defaults* — margin resets, a base colour — that consumers may freely override.