BlogSNIPPET

CSS Nesting: Selektoren nativ verschachteln

CSS Nesting bringt verschachtelte Selektoren direkt in die Sprache, ganz ohne Sass oder Less. Der Ampersand referenziert dabei den Elternselektor. Bei Selektorlisten folgt seine Spezifität denselben Regeln wie :is(), mit Folgen, die im Stylesheet leicht zu übersehen sind.

von Oli Feiler · 16. August 2026

Wer CSS mit Sass oder Less gelernt hat, kennt verschachtelte Selektoren seit Jahren als Selbstverständlichkeit. Eine einzelne .card-Komponente mit Titel, Hover-Zustand und responsivem Verhalten verlangte in reinem CSS bislang drei oder vier getrennte Blöcke, jeder mit dem vollen Klassennamen am Anfang. CSS Nesting trägt diese Schreibweise jetzt direkt in die Sprache, ohne Präprozessor und ohne Build-Schritt dazwischen.

Der Elternselektor mit dem Ampersand

Das Zeichen & steht für den Selektor der umschließenden Regel. Es wird überall dort gebraucht, wo die verschachtelte Regel unmittelbar an den Elternselektor anschließen soll, etwa bei Pseudoklassen, Modifier-Klassen oder Pseudoelementen.

            .card {
  padding: 1.5rem;
  border-radius: 0.75rem;
  background: #ffffff;

  &:hover {
    box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12);
  }

  &.is-featured {
    border: 2px solid #6366f1;
  }

  &::after {
    content: "";
    display: block;
    height: 2px;
    background: currentColor;
  }
}
        

Der Browser löst das zu .card:hover, .card.is-featured und .card::after auf. Steht dagegen ein eigener Selektor durch ein Leerzeichen getrennt im verschachtelten Block, entsteht automatisch ein Nachfahren-Kombinator, ganz ohne Ampersand:

            .card {
  .title {
    font-size: 1.25rem;
    font-weight: 600;
  }
}
        

Das entspricht schlicht .card .title. Der Ampersand ist also kein generelles Verschachtelungszeichen. Gebraucht wird er vor allem dort, wo der Elternselektor ausdrücklich Teil des neuen Selektors werden soll, etwa ohne Leerzeichen bei Pseudoklassen, Modifier-Klassen und Pseudoelementen wie im Beispiel oben. Er muss dabei nicht am Anfang stehen:

            .card {
  background: #ffffff;
  color: #111827;

  .dark-theme & {
    background: #111827;
    color: #ffffff;
  }
}
        

Die verschachtelte Regel landet zwar im .card-Block, wirkt aber wie .dark-theme .card. Der Ampersand kehrt die Nachfahren-Beziehung um: .card wird zum Nachfahren von .dark-theme, statt der Elternselektor voranzustehen. Genau dieses Muster eignet sich für Theme- oder Kontext-Klassen auf einem Vorfahren-Element.

Element-Selektoren am Blockanfang

Eine Weile lang galt für Selektoren, die mit einem reinen Element-Namen beginnen (h2, p, button), eine Sonderregel: Manche Engines verlangten hier zwingend den Ampersand, weil ein Element-Name am Zeilenanfang sonst mit einer CSS-Deklaration verwechselt werden konnte. Diese Ambiguität ist inzwischen aufgelöst, sodass beide Varianten funktionieren: Chrome unterstützt die vollständige Syntax ab Version 120, Safari ab 17.2, Firefox ab 117. Laut caniuse.com liegt die globale Browserabdeckung für CSS Nesting inzwischen bei rund 94 Prozent.

            .card {
  & h2 {
    margin: 0 0 0.5rem;
  }

  p {
    color: #4b5563;
  }
}
        

Wer Wert auf explizite Lesbarkeit legt oder ältere Engine-Versionen im Blick behalten muss, schreibt den Ampersand trotzdem konsequent mit. Ein Automatismus, der nichts kostet, aber Missverständnisse beim Lesen vermeidet.

Was anders funktioniert als in Sass

Wer von Sass kommt, sollte eine Grenze kennen, an der sich natives Nesting bewusst anders verhält. In Sass baut der Ampersand Klassennamen durch Textverkettung zusammen:

            // Sass
.card {
  &__title {
    font-weight: 600;
  }
}
        

Das ergibt .card__title. Native CSS behandelt & als Selektor und nicht als Zeichenkette, die sich um ein Suffix verlängern ließe. In einem zusammengesetzten Selektor muss ein Typselektor wie __title vor dem & stehen, nicht danach. &__title ist deshalb kein gültiger Selektor, und die gesamte verschachtelte Regel wird verworfen. BEM-Klassen wie .card__title müssen deshalb weiterhin ausgeschrieben werden:

            .card {
  .card__title {
    font-weight: 600;
  }
}
        

Verschachtelte @-Regeln

Media Queries, Container Queries und Feature-Abfragen lassen sich direkt im Selektorblock unterbringen, ohne ihn zu verlassen und an anderer Stelle im Stylesheet wieder aufzugreifen:

            .card {
  display: grid;
  gap: 1rem;

  @media (min-width: 48rem) {
    grid-template-columns: 1fr 1fr;
  }

  @container (min-width: 20rem) {
    padding: 2rem;
  }
}
        

Die Regel für den Grid-Wechsel steht damit direkt bei der Komponente, die sie betrifft, statt in einem separaten Media-Query-Abschnitt weiter unten in der Datei.

Anders als bei Element-Selektoren am Blockanfang gibt es bei @media kein Ambiguitätsproblem: Das @-Zeichen ist für den Parser eindeutig, ein Tag-Name wie h2 dagegen nicht. In Chrome und Safari funktionierte das Nesting von @media deshalb schon während der frühen Teilunterstützung, ab Chrome 112 beziehungsweise Safari 16.5. Firefox stieg dagegen erst mit Version 117 direkt und vollständig ein, ohne vorherige Teilunterstützung. Für den strategischen Einsatz in einem Projekt bleibt deshalb dieselbe Schwelle maßgeblich wie für CSS Nesting insgesamt: Chrome 120, Safari 17.2, Firefox 117. Muss ein Projekt ältere Browser berücksichtigen, lässt sich CSS Nesting über @supports (selector(&)) gezielt als Progressive Enhancement einsetzen, alternativ bleibt ein Präprozessor.

Ein Hinweis zur Spezifität

Verschachtelung bei einer Selektorliste als Elternselektor verhält sich hinsichtlich der Spezifität wie :is(), und das kann überraschende Folgen haben:

            .card, #hero {
  & .title {
    color: #111827;
  }
}
        

Diese Regel entspricht :is(.card, #hero) .title, und :is() übernimmt dabei die Spezifität seines höchstspezifischsten Arguments, hier also die der ID #hero. Trifft ein Element tatsächlich nur über .card zu, erbt die Regel trotzdem die hohe Spezifität von #hero, obwohl diese ID für das Element gar nicht gematcht hat. Nicht der Selektor, der im konkreten Fall greift, bestimmt also die Spezifität der Verschachtelung, sondern die gesamte Elternliste. Ein guter Grund, verschachtelte Elternlisten mit gemischter Spezifität bewusst einzusetzen statt beiläufig.

Zusammenfassung

TechnikZweck
& (Ampersand)Expliziter Verweis auf den Elternselektor, nötig für Pseudoklassen, Modifier-Klassen, Pseudoelemente
Verschachtelung ohne &Erzeugt automatisch einen Nachfahren-Kombinator (Leerzeichen)
Element-Selektor am BlockanfangHistorische Sonderregel inzwischen aufgelöst, & bleibt als explizite Schreibweise sinnvoll
.kontext & (Ampersand nicht am Anfang)Kehrt die Nachfahren-Beziehung um, .card wird zum Nachfahren von .kontext
&suffix als TextverkettungFunktioniert in Sass, ist in nativem CSS kein gültiger Selektor
Verschachtelte @media/@container/@supportsAt-Regeln direkt im Selektorblock, ohne ihn zu verlassen
Vollständige SyntaxChrome/Edge 120, Safari 17.2, Firefox 117, ältere Versionen teilweise oder ohne Unterstützung
:is()-Auflösung bei ElternlistenSpezifität richtet sich nach dem höchstspezifischsten Listeneintrag

Glossar

CSS Nesting

Native CSS-Syntax, mit der Selektoren innerhalb anderer Selektoren geschachtelt werden können, ohne Präprozessor wie Sass oder Less.

Ampersand (&)

Platzhalter für den Selektor der umschließenden Regel innerhalb eines verschachtelten Blocks.

Nachfahren-Kombinator

Das Leerzeichen zwischen zwei Selektoren, das eine Nachfahren-Beziehung im DOM beschreibt, etwa .card .title.

:is()

Pseudoklasse, die eine Liste von Selektoren zusammenfasst und dabei die Spezifität ihres höchstspezifischsten Arguments annimmt.

Spezifität

Das Regelwerk, mit dem der Browser bei widersprüchlichen CSS-Regeln entscheidet, welche Deklaration gewinnt.

Mehr CSS entdecken...

 alt=

Struktur als Gestaltungsprinzip.

Wir entwickeln Websites, deren Aufbau sich von der Idee bis zum Code durchzieht, klar, wartbar und ohne unnötige Umwege.
Oli Feiler, UI/UX-Designer