In Sass, `.card { &__title { } }` compiles to `.card__title`. Why does that pattern not work with native CSS nesting, and what forms of & are valid there?

## Two different ampersands Sass runs before the browser sees anything. Its `&` is a token the compiler substitutes textually, which is why suffixing works: `&__title` inside `.card` produces the literal string `.card__title`. The emitted selector is a plain class selector; the relationship to `.card` exists only in your source file, not in the cascade. Native CSS nesting has no compiler. `&` is a **selector** that the engine evaluates against the DOM, standing for the enclosing rule's selector list. Selectors are made of simple selectors joined by combinators; there is no operation in the selector grammar that concatenates two selectors into a new identifier. So the Sass suffix trick has no native counterpart — not because browsers chose not to support it, but because nothing in the model could express it. ## What actually happens to &__title ```css .card { &__title { color: red; } /* invalid — rule discarded */ } ``` The tokenizer sees `&` followed immediately by the identifier `__title`, i.e. a compound selector consisting of the nesting selector and a type selector. A type selector is only allowed as the *first* component of a compound, so the whole selector is invalid, and CSS's error handling throws away the entire rule — silently. The same fate meets `&-active`, `&_wrapper`, and `&--large`. Nothing is logged in normal browsing; devtools show the rule struck through or absent, which is the quickest way to confirm it. ## What is valid Anything that is a legal selector once `&` is treated as a simple selector: ```css .btn { &:hover { … } /* .btn:hover — compound with a pseudo-class */ &.is-active { … } /* .btn.is-active — compound with a class */ &[disabled] { … } /* .btn[disabled] — compound with an attribute */ & .icon { … } /* .btn .icon — descendant */ & > .label { … } /* .btn > .label — child */ & + & { … } /* .btn + .btn — adjacent siblings */ .theme-dark & { … } /* .theme-dark .btn — contextual */ } ``` Note the pattern: `&` compounds with things that *attach* to an element (class, ID, attribute, pseudo-class) and combines with things that *relate* elements (descendant, child, sibling). It never builds a name. ## Consequences for BEM BEM stylesheets written in Sass lean hard on suffixing, both for elements (`&__title`) and modifiers (`&--large`). Ported to native nesting, those blocks must be written out: ```css .card { padding: 1rem; } .card__title { font-weight: 700; } .card--large { padding: 2rem; } ``` That is arguably the honest form — a grep for `.card__title` now finds the rule, which the Sass version famously prevented — but it does mean native nesting does not compress a BEM sheet the way Sass did. The idiom that survives is *state* nesting: `.card { &.is-selected { … } }` is a compound, so it works natively and keeps the class name greppable in full. ## Other differences worth naming Beyond concatenation, the same source can behave differently in the two systems: - **Specificity.** Sass emits each branch of a parent selector list separately; native `&` scores like `:is()`, taking the highest specificity in the list. A heterogeneous parent list therefore raises the score of everything nested under it. - **Sass-only syntax.** `//` comments, `$variables`, `@mixin`/`@include`, `@extend`, nested properties (`font: { size: 1rem; }`) and Sass functions have no native equivalent; custom properties replace some variable uses but not mixins. - **Runtime resolution.** Native nesting is parsed by the browser, so the nested source is what ships and what devtools show — there is no flattened output file to inspect. ## The check to run When a nested rule silently does nothing, the first question is whether the selector is valid at all. Paste the flattened form into `document.querySelectorAll` or the devtools search box; if it throws or matches nothing, you have a parse error rather than a cascade problem — and a `&` glued to an identifier is the most common cause in a codebase migrating away from Sass.