Lesson 2 of 30

Native CSS Nesting

Q: A teammate coming from Sass writes `.card { .title { color: red; } }` using native CSS nesting and expects `.title` styles here to only ever apply inside `.card` instances, never leaking elsewhere. Is that expectation correct, and how would you explain what's actually happening?

A strong answer covers: Correctly identifies that the expectation is wrong — the nested rule flattens to the plain descendant selector `.card .title`, with the same global reach as writing it flat; Explains nesting is purely selector-writing convenience, compiling to the equivalent flat selector, not a scoping or isolation feature; Mentions @scope as the actual mechanism for real style isolation to a subtree, distinct from nesting.

Sass popularized writing nested selectors two decades ago. Now the browser does it natively — no build step, with one syntax quirk Sass never made you think about.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

`.card { .title { font-weight: 600; } }` is written using native CSS nesting. What selector does this actually compile down to and match against?

It's invalid without an `&` before `.title`, since all nested selectors require the nesting selector explicitly`.card .title` — a plain descendant selector, matching any .title inside any .card, anywhere in the documentOnly `.title` elements that are direct, isolated children scoped exclusively to this one .card instance

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Native CSS Nesting

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate coming from Sass writes `.card { .title { color: red; } }` using native CSS nesting and expects `.title` styles here to only ever apply inside `.card` instances, never leaking elsewhere. Is that expectation correct, and how would you explain what's actually happening?

A strong answer covers

Correctly identifies that the expectation is wrong — the nested rule flattens to the plain descendant selector `.card .title`, with the same global reach as writing it flat
Explains nesting is purely selector-writing convenience, compiling to the equivalent flat selector, not a scoping or isolation feature
Mentions @scope as the actual mechanism for real style isolation to a subtree, distinct from nesting

Likely follow-ups

Why does `&:hover { ... }` require the & while `.title { ... }` nested the same way doesn't?
If a team needs to support older browsers that don't parse native nesting, what's the safer approach — an @supports fallback, or something else?

Practice these with the AI interviewer →

The plain-language idea

Native CSS nesting lets you write a selector inside another selector's rule block, instead of repeating the parent selector on every line. It ships in the browser itself — no Sass, Less, or PostCSS plugin required. The nested rule still compiles down to exactly the same flat selector you'd have written by hand; nesting is sugar for writing less repetitive CSS, not a new capability.

The one thing that trips people up coming from Sass: native nesting sometimes requires an explicit & (the "nesting selector," standing in for the parent selector) where Sass would have let you omit it. The rule is about ambiguity — if what follows the parent selector could be parsed as the start of a new declaration instead of a new selector, the & is required to disambiguate it.

See it in a real thing: a card component's hover and child styles

The old, flat way:

.card { border-radius: 8px; }
.card:hover { box-shadow: 0 4px 12px rgb(0 0 0 / 0.15); }
.card .title { font-weight: 600; }
.card .title:hover { color: var(--color-accent); }

The nested way:

.card {
  border-radius: 8px;

  &:hover {
    box-shadow: 0 4px 12px rgb(0 0 0 / 0.15);
  }

  .title {
    font-weight: 600;

    &:hover {
      color: var(--color-accent);
    }
  }
}

Nesting flattens to the exact same selectorStep 1 of 4

Written as nested rules: .card contains &:hover and .title, and .title contains its own &:hover.

&:hover needs the & because :hover alone, nested directly, would be ambiguous with the compound selector shorthand. .title on its own line doesn't need one — nesting a selector that starts with a type, class, or ID selector reads unambiguously as descendant combination, exactly like Sass. Either way, .card .title:hover is the flattened selector the browser actually matches against — nesting is purely a way to write that string more concisely.

What people usually miss

Watch out

Nested rules are not scoped — they flatten to the same global selector you'd write by hand. .card { .title {...} } produces .card .title, a plain descendant selector with the exact same global reach as if you'd never nested anything.
The & is required specifically to avoid ambiguity with a plain declaration, not as a stylistic preference — nesting a pseudo-class, an attribute selector, or anything that doesn't unambiguously start a new selector typically needs it.
Nesting compiles to a selector list under the hood, so nesting under @media or other at-rules also works, but nesting a declaration (a plain property: value line) directly among nested rules can get confusing to read even when it's technically valid — most teams still group declarations before nested rules for readability.
Support is Baseline / widely available now, but if you need to support meaningfully older browsers, this is a case where a build-time preprocessor (Sass, PostCSS) that compiles nesting down to flat CSS ahead of time is still the safer choice — not an @supports runtime fallback, since there's no reasonable degraded experience for "nesting doesn't work."
It's purely a selector-writing convenience, not a performance or specificity change. The specificity of the flattened selector is exactly what it would have been written flat — nesting doesn't add or remove specificity on its own.

Why this matters in interviews

"What's the difference between CSS nesting and Sass nesting?" is a real question, and the sharp answer is the scoping misconception: interviewers are checking whether a candidate understands nesting is purely selector-writing syntax that flattens to global selectors, not a way to isolate a component's styles from the rest of the page.