CSS Nesting: native Verschachtelung ohne Präprozessor 2026

1. Warum natives CSS Nesting ein Wendepunkt ist

Seit den frühen Tagen von Sass und Less war CSS Nesting das beliebteste Feature von CSS-Präprozessoren. Die Möglichkeit, Regeln für Kindelemente innerhalb des Elternelements zu schreiben, reduziert Wiederholungen, verbessert die Lesbarkeit und macht die Beziehung zwischen Selektor und Context explizit sichtbar. Jahrelang war dieses Feature ausschließlich über einen Build-Step zugänglich – Sass-, Less- oder PostCSS-Dateien mussten kompiliert werden, bevor der Browser sie verarbeiten konnte. Mit der Einführung von nativem CSS Nesting in allen modernen Browser-Engines ist dieser Build-Step für viele Anwendungsfälle nicht mehr notwendig.

Natürlich heißt das nicht, dass Sass von heute auf morgen obsolet wird. Sass bietet darüber hinaus Variablen (die heute durch Custom Properties übernommen werden), Funktionen, Mixins und komplexe Logik, die in nativem CSS nicht existieren. Aber das Hauptmotiv für den Einsatz von Sass in vielen Projekten – eben CSS Nesting – ist 2026 mit nativem CSS erreichbar. Wer heute ein neues Projekt startet, kann in vielen Fällen komplett auf einen CSS-Präprozessor verzichten. Das vereinfacht das Build-Setup, reduziert Abhängigkeiten und eliminiert eine ganze Klasse von Source-Map-Problemen beim Debugging in den Browser-DevTools.

2. Der & Selector: Bedeutung und Mechanismus

Der & Selector ist das Herzstück von CSS Nesting. Er steht für den Selector des übergeordneten Regelblocks und ermöglicht es, Modifikatoren, Pseudo-Klassen und Pseudo-Elemente direkt innerhalb des Elternblocks zu definieren. In Sass war dieses Verhalten bekannt und verbreitet: .button { &:hover { } } wurde zu .button:hover { } kompiliert. Im nativen CSS Nesting ist das Verhalten identisch – der Browser führt die Selector-Konkatenation intern durch, ohne dass ein Build-Step nötig ist.

Der & Selector kann an jeder Position im verschachtelten Selektor stehen – nicht nur am Anfang. .child { .parent & { color: red; } } erzeugt .parent .child { color: red; } – eine Kontextmodifikation, bei der das Element nur innerhalb eines bestimmten Elternkontexts gestylt wird. Das ist besonders nützlich für Theme-Varianten: Ein dunkler Container kann Kind-Elemente über .dark-theme & { } innerhalb des Kind-Selektor-Blocks umfärben, ohne den Selektor doppelt schreiben zu müssen. Diese Flexibilität des & im CSS Nesting geht in einigen Aspekten sogar über das hinaus, was Sass standardmäßig bietet.

/* Native CSS Nesting — no preprocessor required */
.card {
  background: white;
  border-radius: 0.75rem;
  padding: 1.5rem;

  /* & = .card — pseudo-class nesting */
  &:hover {
    box-shadow: 0 4px 24px rgba(0, 0, 0, 0.12);
    transform: translateY(-2px);
  }

  /* & = .card — modifier class nesting */
  &.card--featured {
    border: 2px solid #7c3aed;
  }

  /* Descendant nesting */
  .card__title {
    font-size: 1.25rem;
    font-weight: 700;
  }

  /* & in non-initial position — context modifier */
  .dark-theme & {
    background: #1e1b4b;
    color: white;
  }

  /* Pseudo-element nesting */
  &::before {
    content: '';
    display: block;
    height: 4px;
    background: linear-gradient(90deg, #7c3aed, #c4b5fd);
    border-radius: 4px 4px 0 0;
  }
}

3. Implizites Nesting: & als optionales Element

Seit der Überarbeitung der CSS Nesting-Spezifikation (Relaxed Nesting) ist der & Selector für Element-Selektoren, Klassen-Selektoren und ID-Selektoren nicht mehr zwingend erforderlich, wenn der verschachtelte Selektor eindeutig als Kindelement erkannt werden kann. Das bedeutet: .parent { .child { } } entspricht .parent { & .child { } } – der Browser ergänzt den & implizit. Das vereinfacht die Migration von Sass-Code erheblich, da viele Sass-Dateien verschachtelte Selektoren ohne explizites & verwenden.

Wichtig zu verstehen: Das implizite CSS Nesting ohne & funktioniert nur für einfache Selektoren, die mit einem Tag, einer Klasse oder einer ID beginnen. Pseudo-Klassen und Pseudo-Elemente benötigen weiterhin das explizite &. Auch komplexere Selektoren wie :is(), :not() und Combinator-Selektoren erfordern den & für klare Semantik. Die Faustregel für gut wartbares CSS Nesting: Immer dann, wenn es um direkte Modifikation des Elternselektors geht (Pseudo-Klassen, Pseudo-Elemente, Modifier-Klassen), explizit & schreiben. Für echte Kindelemente kann der & weggelassen werden – aber Konsistenz innerhalb eines Projekts ist wichtiger als das Weglassen einzelner Zeichen.

4. Verschachtelte @media und @supports Queries

Das mächtigste Feature des nativen CSS Nesting ist die Möglichkeit, @media-, @supports- und @layer-Regeln innerhalb eines Selektor-Blocks zu verschachteln. Das dreht die traditionelle CSS-Struktur um: Statt eine Media Query global zu definieren und darin alle betroffenen Selektoren aufzulisten, schreibt man die Selektoren mit ihren Basis-Styles und definiert die responsiven Abweichungen direkt daneben. Das hält zusammengehörigen Code zusammen – eine Eigenschaft ist an einem Ort definiert, statt auf fünf verschiedene Media Query Blöcke verteilt zu sein.

Diese Umkehrung der Struktur hat erhebliche Auswirkungen auf die Wartbarkeit großer CSS-Codebases. Wenn eine Komponente geändert werden muss, sind alle relevanten Styles an einem Ort – der Entwickler muss nicht mehr durch die gesamte Datei scrollen, um alle Media Query Blöcke zu finden, die die Komponente betreffen. Das ist ein Hauptvorteil von CSS Nesting gegenüber klassischem Flat-CSS, der über reine Syntax-Verschachtelung hinausgeht. Sass hat dieses Muster popularisiert, aber das native CSS Nesting macht es ohne Build-Step verfügbar.

/* Nested @media — responsive styles colocated with component */
.hero {
  font-size: 1.5rem;
  padding: 2rem;

  /* Responsive breakpoint — right next to base styles */
  @media (min-width: 768px) {
    font-size: 2.5rem;
    padding: 4rem;
  }

  @media (min-width: 1024px) {
    font-size: 3.5rem;
    padding: 6rem 4rem;
  }

  /* Feature detection — nested @supports */
  @supports (display: grid) {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

/* Nested @layer for cascade control */
@layer components {
  .button {
    padding: 0.5rem 1rem;
    border-radius: 0.375rem;

    &:hover {
      opacity: 0.9;
    }

    /* Layer override from within the block */
    @layer overrides {
      &.button--ghost {
        background: transparent;
      }
    }
  }
}

/* Container queries nested inside selector */
.sidebar-widget {
  padding: 1rem;

  @container (min-width: 300px) {
    padding: 1.5rem;
    display: flex;
    gap: 1rem;
  }
}

5. Spezifität im CSS Nesting: was sich ändert

Die Spezifitätsberechnung im nativen CSS Nesting entspricht der Sass-Spezifität: Ein verschachtelter Selektor berechnet seine Spezifität aus der Konkatenation des Elternselektors und des verschachtelten Selektors. .parent .child hat dieselbe Spezifität egal ob direkt geschrieben oder durch CSS Nesting erzeugt. Es gibt keine Sonderbehandlung, keine erhöhte Spezifität durch die Verschachtelung selbst. Das ist ein wichtiger Unterschied zu häufigen Missverständnissen: CSS Nesting erzeugt keine neuen Spezifitäts-Ebenen.

Eine subtile Ausnahme betrifft den & Selector in Kombination mit :is(). Wenn der & eine Liste von Selektoren repräsentiert (etwa durch mehrere Selektoren vor dem verschachtelten Block), wird die Spezifität nach den Regeln von :is() berechnet – also nach dem spezifischsten Selektor in der Liste. Das kann zu unerwarteten Spezifitätsunterschieden führen. Für gut wartbares CSS Nesting empfiehlt sich daher, Selektorlisten vor einem Verschachtelungsblock zu vermeiden und stattdessen einzelne Selektoren zu bevorzugen. Wo Selektorlisten nötig sind, sollte die Spezifität bewusst überprüft werden.

6. Sass-Migration: was 1:1 funktioniert, was nicht

Die Migration von Sass zu nativem CSS Nesting ist für die meisten einfachen Verschachtelungsfälle unkompliziert. Sass-Code wie .nav { .nav-item { } } funktioniert in nativem CSS identisch. Pseudo-Klassen mit &:hover { }, Modifier-Klassen mit &.is-active { } und Pseudo-Elemente mit &::before { } sind ebenfalls direkt übertragbar. Das ist der Großteil der alltäglichen Sass-Nutzung in Komponentenstyles.

Was in nativem CSS Nesting nicht funktioniert: Sass-Variablen ($color: red) – diese werden durch CSS Custom Properties (--color: red) ersetzt. Sass-Mixins (@mixin, @include) – diese haben kein natives CSS-Äquivalent und erfordern entweder Custom Properties, CSS-Funktionen oder die Akzeptanz von Code-Wiederholung. Sass-Schleifen (@each, @for) – diese werden in nativem CSS nicht unterstützt. Für Projekte, die intensiv von Mixins und Loops Gebrauch machen, ist Sass weiterhin die richtige Wahl. Für Projekte, die Sass primär für Verschachtelung und Variablen einsetzen, ist die Migration zu nativem CSS Nesting plus Custom Properties oft möglich und lohnend.

/* BEM component with native CSS Nesting — migration from Sass */

/* Before: Sass */
/* .nav {
  &__item { color: gray; }
  &__item--active { color: purple; }
  &__link { &:hover { color: purple; } }
} */

/* After: native CSS Nesting */
.nav {
  display: flex;
  gap: 0.5rem;

  /* BEM element */
  .nav__item {
    list-style: none;

    /* BEM modifier — explicit & required */
    &.nav__item--active {
      font-weight: bold;
    }
  }

  /* BEM element with state */
  .nav__link {
    color: #64748b;
    text-decoration: none;
    transition: color 0.2s;

    &:hover,
    &:focus-visible {
      color: #7c3aed;
    }

    &[aria-current="page"] {
      color: #4a1d96;
      font-weight: 600;
    }
  }

  /* Responsive — colocated with component */
  @media (max-width: 640px) {
    flex-direction: column;
  }
}

7. CSS Nesting mit @layer und @scope

Das native CSS Nesting entfaltet sein volles Potenzial in Kombination mit den neueren CSS-At-Rules @layer und @scope. @layer definiert eine Cascade-Schicht mit explizit gesetzter Priorität – Styles in einer niedrigeren Schicht werden von Styles in einer höheren Schicht überschrieben, unabhängig von der Spezifität. CSS Nesting innerhalb von @layer erlaubt es, Komponenten-Styles vollständig in ihrer Layer-Schicht zu kapseln, ohne die Selektor-Hierarchie zu verlassen. Das Ergebnis ist eine CSS-Architektur, die Cascade-Konflikte durch strukturelle Schichten löst statt durch Spezifitätswettrüsten mit !important.

@scope ist das neueste Mitglied im CSS-At-Rule-Repertoire und begrenzt den Geltungsbereich eines Selektor-Blocks auf einen bestimmten DOM-Teilbaum. In Kombination mit CSS Nesting entstehen so echte Komponenten-Stile ohne Shadow DOM: @scope (.card) stellt sicher, dass alle Selektoren innerhalb des Blocks nur Elemente treffen, die Nachkommen eines .card-Elements sind. Das löst das klassische Problem von CSS-Klassen, die unbeabsichtigt andere Stellen im DOM treffen, wenn Klassennamen wiederverwendet werden – und macht CSS Nesting zu einem vollwertigen Werkzeug für komponentenbasierte CSS-Architektur.

8. Praxispatterns: BEM, Modifier und States

Das häufigste Praxispattern für CSS Nesting in komponentenbasiertem CSS ist die Abbildung von BEM-Strukturen. Ein BEM-Block wird zum äußersten Selektor, BEM-Elemente (__element) und BEM-Modifier (--modifier) werden verschachtelt. Das Ergebnis ist deutlich kompakterer Code als in klassischem Flat-BEM-CSS, bei dem Block, Elemente und Modifier als separate, voneinander getrennte Regelblöcke geschrieben werden. Die Zugehörigkeit aller Regeln zur selben Komponente wird durch die Verschachtelung visuell sofort erkennbar.

States wie .is-open, .is-loading und Aria-Attribute wie [aria-expanded="true"] werden mit dem &-Selector direkt neben den Basis-Styles der Komponente verschachtelt. Das macht State-Management im CSS deutlich übersichtlicher: Statt in einer langen Flat-CSS-Datei nach dem passenden State-Selektor zu suchen, findet er sich direkt neben den Basis-Styles. In der täglichen Entwicklungsarbeit mit komponentenbasiertem CSS Nesting bedeutet das: jede Komponente ist ein in sich geschlossener Block, der vollständig in einer einzigen Regel-Hierarchie definiert ist – Base Styles, States, Modifier und responsive Abweichungen an einem Ort.

9. CSS Nesting vs. Sass im direkten Vergleich

Die Entscheidung zwischen nativem CSS Nesting und Sass ist 2026 nuancierter als früher. Für neue Projekte, die keine komplexen Mixins, keine Loops und keine Sass-Funktionen benötigen, spricht viel für natives CSS Nesting: kein Build-Step, keine Source-Map-Probleme, direktes Debugging im Browser, geringere Abhängigkeiten und automatisch aktueller Browser-Support ohne manuelle Präfix-Verwaltung. Der Browser DevTools zeigen das native CSS direkt an, nicht das kompilierte Ergebnis.

Für Projekte, die bereits eine etablierte Sass-Architektur mit Mixins und Utility-Funktionen haben, ist eine Migration kurzfristig nicht sinnvoll. Sass und natives CSS Nesting können problemlos koexistieren – Sass-Dateien, die mit PostCSS in natives CSS kompiliert werden, profitieren sogar davon, wenn der Output natives CSS Nesting preserviert statt es aufzulösen. Das ermöglicht einen graduellen Übergang: Neue Komponenten werden mit nativem CSS Nesting geschrieben, alte Sass-Komponenten bleiben bestehen, bis sie refaktoriert werden.

/* Complete component — native CSS Nesting, no Sass */
.dropdown {
  position: relative;
  display: inline-block;

  /* Trigger button */
  .dropdown__trigger {
    padding: 0.5rem 1rem;
    background: #7c3aed;
    color: white;
    border: none;
    border-radius: 0.5rem;
    cursor: pointer;

    &:hover { background: #6d28d9; }
    &:focus-visible { outline: 2px solid #c4b5fd; }
  }

  /* Menu panel */
  .dropdown__menu {
    display: none;
    position: absolute;
    top: 100%;
    left: 0;
    background: white;
    border: 1px solid #e2e8f0;
    border-radius: 0.5rem;
    box-shadow: 0 4px 24px rgba(0,0,0,0.12);
    min-width: 200px;
    z-index: 50;
  }

  /* Open state — parent class modifier */
  &.is-open {
    .dropdown__menu {
      display: block;
    }
    .dropdown__trigger {
      background: #4a1d96;
    }
  }

  /* Responsive: fullscreen on mobile */
  @media (max-width: 640px) {
    .dropdown__menu {
      position: fixed;
      inset: 0;
      border-radius: 0;
    }
  }
}

10. Zusammenfassung

Natives CSS Nesting ist 2026 in allen modernen Browsern vollständig unterstützt und macht für viele Projekte den Einsatz eines CSS-Präprozessors überflüssig. Der & Selector ermöglicht Pseudo-Klassen, Pseudo-Elemente und Modifier-Klassen direkt innerhalb des Elternblocks. Relaxed Nesting erlaubt das Weglassen des & bei einfachen Kindelement-Selektoren. Verschachtelte @media-, @supports- und @layer-Regeln halten responsive Styles und Feature-Detections zusammen mit den Basis-Styles der Komponente.

Die Migration von Sass zu nativem CSS Nesting ist für den Großteil der Verschachtelungs-Nutzung 1:1 möglich. Sass-Variablen werden durch Custom Properties ersetzt, Mixins bleiben als einziges wesentliches Feature ohne natives CSS-Äquivalent. Für neue Projekte empfiehlt sich natives CSS Nesting mit @layer als CSS-Architektur-Fundament – weniger Abhängigkeiten, einfacheres Debugging, zukunftssichere Standards.

11. FAQ: CSS Nesting — native Verschachtelung