In the past, writing styles that mirror a "parent-child structure" required a preprocessor (Sass/Less) to expand them at build time. Browsers now support the nesting syntax natively: with no build tool at all, you can organize rules by DOM hierarchy directly in a .css file and stop repeating the parent selector.
Basic Nesting Syntax
Inside the braces of one selector, you can directly write another rule that uses it as its parent:
Child rules are automatically expanded to "parent selector + descendant selector", so you never repeat .card. This is almost identical to Sass nesting, except that the browser parses it natively and no build step is needed.
The & Symbol and Compound Selectors
When a child rule is not a "descendant" relationship but has to be appended to the parent selector (for example pseudo-classes, modifier classes), you must explicitly use & to stand for the parent selector itself:
RuleIf a nested rule starts with a tag name (such as p or span), it is automatically expanded as a descendant selector; but if it starts with a pseudo-class (:hover) or a class attached to the current element (.is-disabled), you must write &, otherwise it is parsed as a selector with a completely different meaning.
Nested @media and @supports
Conditional group rules (@media, @supports, @container) can also be nested directly inside a selector, so a component's styles don't get scattered across different parts of the file:
Pseudo-classes/compound selectors attached to the current element must include & explicitly, otherwise they are treated as descendant selectors with a completely different meaning
Over-nesting
The deeper the nesting, the higher the specificity of the generated selectors and the harder they are to override; generally stay within 2-3 levels
Differences from Sass nesting
Native nesting parses selectors more strictly (for example, some cases require an explicit &), so migrating Sass code needs to be checked rule by rule