# CSS @layer in der Praxis: Kaskadenebenen statt Spezifitätskrieg
> Cascade Layers von Grund auf: Syntax, Kaskaden-Reihenfolge, Frameworks wie Bootstrap und Tailwind im eigenen Layer, Shadow DOM und Design-Tokens.
Source: https://www.jpkc.com/db/blog/css-cascade-layers/
Es gibt eine Zeile CSS, die fast jeder schon geschrieben hat und danach bereut:
```css
.sidebar .widget ul li a.link { color: #fff !important; }
```
Diese Zeile ist kein Styling. Sie ist eine Kapitulation. Jemand wollte eine Farbe ändern, ist an einem Selektor gescheitert, hat einen weiteren Klassennamen davorgesetzt, ist wieder gescheitert, und am Ende kam das `!important` dazu. Das Ergebnis funktioniert — bis jemand anderes dasselbe Spiel eine Ebene höher spielt.
Genau dafür gibt es seit März 2022 in allen Browser-Engines eine Lösung: **Cascade Layers**, die At-Rule `@layer`. At-Rules sind CSS-Anweisungen, die mit einem `@` beginnen — `@media`, `@import`, `@supports`; sie enden entweder mit Semikolon oder umschließen einen eigenen Block. Diese hier fügt der CSS-Kaskade eine Ebene hinzu, die *über* der Spezifität liegt. (Die Kaskade ist der Algorithmus, mit dem der Browser bei konkurrierenden Angaben für dieselbe Eigenschaft einen Gewinner bestimmt — nicht zu verwechseln mit der Vererbung.) Statt Selektoren aufzublähen, sagst du einmal, in welcher Reihenfolge deine Stil-Schichten gelten sollen — und danach gewinnt die spätere Schicht, egal wie schwach ihr Selektor ist.
Dieser Artikel ist die ausführliche Tour: die Regeln (jede davon im Browser nachgemessen, nicht aus der Doku abgeschrieben), die Umstellung einer real gewachsenen Website, Frameworks wie Bootstrap und Tailwind in eigenen Layern, das Verhältnis zu Web Components und Shadow DOM — und ein Muster, mit dem Design-Tokens ihre Layer-Zuordnung selbst mitbringen.
> **Methodik-Hinweis:** Alle Verhaltensbehauptungen in diesem Artikel wurden gegen einen echten Browser geprüft (Chromium-Engine, Edge 151, headless, `getComputedStyle`). Wo Dokumentation und Spezifikation sich widersprechen, steht hier das gemessene Ergebnis — an einer Stelle weiter unten ist genau das passiert.
## Das Problem: Spezifität ist ein schlechtes Ordnungssystem
Bevor `@layer` existierte, hattest du in CSS genau drei Hebel, um zu entscheiden, welche von zwei konkurrierenden Deklarationen gewinnt. **Deklaration** meint dabei genau ein `eigenschaft: wert;`-Paar; eine **Regel** ist der Selektor plus der geschweifte Block, der eine oder mehrere Deklarationen enthält. Die drei Hebel:
1. **Herkunft und Wichtigkeit** — Browser-Stylesheet, Nutzer-Stylesheet, Autoren-Stylesheet, plus `!important`.
2. **Spezifität** — die berühmte Zählung von ID-, Klassen- und Element-Selektoren. Der Browser zählt je Selektor drei Stellen: IDs — Klassen, Attribute und Pseudo-Klassen — Elemente und Pseudo-Elemente. `#hinweis` ergibt 1-0-0, `.box.box.box` ergibt 0-3-0, `div.box` ergibt 0-1-1. Verglichen wird von links nach rechts, der höhere Wert gewinnt.
3. **Reihenfolge im Quelltext** — bei Gleichstand gewinnt die letzte Deklaration.
Alle drei sind für kleine Stylesheets völlig ausreichend und für große Projekte ungeeignet. Der Grund ist strukturell: **Spezifität ist eine Eigenschaft des Selektors, nicht der Absicht.** Du willst sagen „diese Regel gehört zu meinem Design-System und darf von Komponenten überschrieben werden". Was du stattdessen sagen kannst, ist „diese Regel hat zwei Klassen und ein Element". Das sind zwei völlig verschiedene Aussagen, und CSS zwingt dich, die zweite zu benutzen, um die erste zu meinen.
Daraus folgt der bekannte Verlauf jedes größeren Projekts:
- Zuerst werden Selektoren länger, um zu gewinnen.
- Dann kommt `!important` dazu, weil Selektoren nicht mehr reichen.
- Dann kommt `!important` in der Gegenrichtung, weil das erste `!important` im Weg ist.
- Am Ende traut sich niemand mehr, irgendetwas zu löschen.
Methodiken wie BEM (Block Element Modifier), SMACSS (Scalable and Modular Architecture for CSS) oder ITCSS (Inverted Triangle CSS) sind allesamt Versuche, dieses Problem mit **Disziplin** zu lösen — über Konventionen für Namensgebung und Datei-Reihenfolge: Halte die Spezifität flach, sortiere die Datei so, dass Allgemeines zuerst und Wichtiges unten steht. Das funktioniert, solange sich alle daran halten — und bricht in dem Moment, in dem Fremd-CSS ins Spiel kommt, das sich naturgemäß nicht an deine Konvention hält.
Cascade Layers lösen das Problem an der richtigen Stelle: Sie machen die **Absicht** zu einem erstklassigen Bestandteil der Kaskade.
## Was Cascade Layers eigentlich sind
Ein Cascade Layer ist ein benannter Eimer für CSS-Regeln. Du legst einmal die Reihenfolge der Eimer fest, danach gilt:
> **Bei konkurrierenden normalen Deklarationen gewinnt der Eimer, der später deklariert wurde — unabhängig von der Spezifität der Selektoren darin.**
Das ist die ganze Grundidee. Alles Weitere sind Details und Sonderfälle.
Das Minimalbeispiel:
```css
@layer basis, komponenten;
@layer basis {
#hinweis { color: red; } /* Spezifität 1-0-0 */
}
@layer komponenten {
.hinweis { color: green; } /* Spezifität 0-1-0 */
}
```
Das Element wird **grün**. Der ID-Selektor verliert gegen einen Klassen-Selektor, weil `komponenten` nach `basis` deklariert wurde. In klassischem CSS wäre das schlicht unmöglich gewesen.
### Die Kaskade in voller Länge
Um `@layer` sicher einzusetzen, muss man wissen, *wo genau* Layer in der Kaskade sitzen. Die Spezifikation ([CSS Cascading and Inheritance Level 5](https://www.w3.org/TR/css-cascade-5/), englisch) sortiert konkurrierende Deklarationen in dieser Reihenfolge — der erste Punkt, der einen Unterschied macht, entscheidet:
1. **Herkunft und Wichtigkeit** (Browser / Nutzer / Autor, jeweils normal und `!important`)
2. **Kapselungskontext** (Shadow-DOM-Baum — dazu weiter unten ein eigenes Kapitel)
3. **Element-gebundene Styles** (das `style`-Attribut)
4. **Layer**
5. **Spezifität**
6. **Reihenfolge im Quelltext**
Zwei Dinge daran sind praktisch wichtig und werden oft übersehen:
**Layer stehen über Spezifität, aber unter Inline-Styles.** Ein `style="color: red"` im HTML schlägt jeden Layer. `@layer` ersetzt also nicht die Regel „keine Inline-Styles im Markup".
**Der Kapselungskontext steht noch über den Layern.** Das ist der Grund, warum `@layer` und Shadow DOM sich anders verhalten, als man zunächst annimmt — das Kapitel dazu kommt später.
Und die vollständige Rangfolge im Autoren-Bereich der Kaskade, von schwach nach stark — die beiden Animations-Ränge sind streng genommen eigene Herkunftsbereiche, die hier hineinragen:
| Rang | Was |
|---|---|
| 1 (schwächster) | Erster Layer, normal |
| 2 | Zweiter Layer, normal |
| … | weitere Layer, normal |
| 3 | **Ungelayerte** Regeln, normal |
| 4 | Inline-Styles, normal |
| 5 | Laufende CSS-Animationen |
| 6 | **Ungelayerte** Regeln, `!important` |
| … | weitere Layer, `!important` — **rückwärts** |
| 7 | Zweiter Layer, `!important` |
| 8 | Erster Layer, `!important` |
| 9 | Inline-Styles, `!important` |
| 10 (stärkster) | Laufende CSS-Transitions |
Die beiden Zeilen, die für Fehler sorgen, sind Rang 3 und Rang 6 — dazu gleich mehr.
## Die Syntax: fünf Formen, mehr gibt es nicht
### 1. Die Reihenfolge-Deklaration
```css
@layer reset, base, components, utilities;
```
Diese Zeile erzeugt vier leere Layer in genau dieser Reihenfolge. Sie sollte ganz oben in deinem Stylesheet stehen — sie ist der Vertrag, den der Rest der Datei erfüllt. Wo die Regeln später tatsächlich stehen, ist danach egal.
Das ist der wichtigste Trick an der ganzen At-Rule: **Die Reihenfolge wird durch die erste Erwähnung eines Layer-Namens festgelegt, nicht durch die Position der Regeln.** Du kannst deine Datei also weiter so sortieren, wie es für Menschen lesbar ist.
### 2. Der Layer-Block
```css
@layer components {
.btn {
border-radius: 0.4rem;
padding: 0.5em 1em;
}
}
```
Du darfst denselben Layer beliebig oft öffnen. Der Browser führt alle Blöcke desselben Namens zu einem Layer zusammen; innerhalb des Layers gelten dann wieder Spezifität und Quelltext-Reihenfolge.
```css
@layer components { .btn { padding: 0.5em 1em; } }
@layer utilities { .p-0 { padding: 0; } }
@layer components { .card { padding: 1rem; } } /* landet trotzdem vor utilities */
```
Das ist keine Schlamperei, sondern die vorgesehene Arbeitsweise für gewachsene Dateien — genau so ist auch die weiter unten beschriebene Umstellung von jpkc.com gelaufen.
### 3. Anonyme Layer
```css
@layer {
/* Regeln ohne Layer-Namen */
}
```
Ein Block ohne Namen erzeugt einen Layer, den niemand mehr referenzieren, erweitern oder umsortieren kann. Jedes weitere `@layer { }` erzeugt einen *neuen* anonymen Layer. Nützlich für Code, den du bewusst abschotten willst; ungeeignet für alles, was du später noch anfassen musst. (Zu *überschreiben* ist ein anonymer Layer dagegen trivial — jeder spätere Layer und jede ungelayerte Regel schlägt ihn.)
### 4. Import in einen Layer
```css
@import url("bootstrap.css") layer(framework);
@import url("legacy.css") layer; /* anonymer Layer */
```
Achte auf die zweite Zeile: Für den anonymen Layer steht das Schlüsselwort **ohne Klammern**. `layer()` mit leeren Klammern sieht plausibel aus, ist aber kein gültiger Wert — und das Fatale daran ist die Fehlerbehandlung: Der gesamte `@import` wird ungültig, das Stylesheet lädt **gar nicht**, und zwar ohne Konsolenfehler. Gemessen: Die importierten Regeln fehlen ersatzlos.
So bekommst du fremde Stylesheets in einen Layer, ohne ihren Inhalt anzufassen. Das ist der Kern des Framework-Kapitels weiter unten.
Wichtig zur Reihenfolge im Dokument: `@import` muss vor allen anderen Regeln stehen — **mit genau zwei Ausnahmen**, `@charset` und `@layer`-**Reihenfolgezeilen**. Gemeint ist dabei ausschließlich die Statement-Form `@layer a, b;`. Ein `@layer name { … }`-**Block** davor macht jedes folgende `@import` ungültig; die Spezifikation hält ausdrücklich fest, dass Layer-Blöcke nicht zwischen `@import`-Regeln stehen dürfen. Das folgende ist also gültig und auch die empfohlene Schreibweise:
```css
@layer framework, app; /* zuerst die Reihenfolge festnageln */
@import url("bootstrap.css") layer(framework); /* dann importieren */
```
### 5. Verschachtelte Layer
```css
@layer components {
@layer card { /* … */ }
@layer button { /* … */ }
}
/* gleichbedeutend, mit Punktnotation: */
@layer components.card { /* … */ }
@layer components.button { /* … */ }
```
Verschachtelte Layer erzeugen eine Unter-Rangfolge innerhalb ihres Elternteils. Der Name ist dabei an den Elternteil gebunden: `components.card` und `utilities.card` sind zwei völlig verschiedene Layer.
Der Sinn ist Kapselung von Namensräumen. Ein Framework kann intern `framework.reset`, `framework.base`, `framework.components` benutzen, ohne dass sich diese Namen mit deinen eigenen `reset`/`base`/`components` beißen.
## Acht Regeln, die du kennen musst
Die folgenden acht Punkte sind das, was in der Praxis tatsächlich zu Überraschungen führt. Jeder ist unten mit dem gemessenen Ergebnis aus einem echten Browser belegt.
### Regel 1: Layer schlägt Spezifität — immer
```css
@layer a, b;
@layer b { #box { color: blue; } } /* 1-0-0 */
@layer a { .box.box.box { color: red; } } /* 0-3-0 */
```
**Gemessen: blau.** Innerhalb eines Layers zählt Spezifität weiter ganz normal. Zwischen Layern zählt sie überhaupt nicht.
Das ist die Eigenschaft, wegen der man `@layer` einsetzt: Du kannst in einem späteren Layer mit einem einzigen Klassen-Selektor etwas überschreiben, das im früheren Layer mit einem ID-Selektor gesetzt wurde.
### Regel 2: Die Reihenfolge steht bei der ersten Erwähnung fest
```css
@layer a { #box { color: red; } }
@layer b { #box { color: green; } }
@layer b, a; /* zu spät */
```
**Gemessen: grün.** Die Layer wurden bereits durch die beiden Blöcke in der Reihenfolge `a, b` angelegt. Die nachträgliche Deklarationszeile ändert nichts mehr — sie erwähnt nur zwei Layer, die es schon gibt.
Praktische Konsequenz: **Eine `@layer`-Reihenfolgezeile ist nur dann wirksam, wenn sie vor allen betroffenen Blöcken steht.** Deshalb gehört sie in die erste Zeile deines Einstiegs-Stylesheets — und in genau eine Datei, nicht in mehrere.
### Regel 3: Ungelayerte Styles gewinnen gegen alle Layer
```css
@layer alles { #box { color: blue; } } /* 1-0-0, im Layer */
div.box { color: green; } /* 0-1-1, ohne Layer */
```
**Gemessen: grün.** Ungelayerte Regeln verhalten sich, als lägen sie in einem impliziten letzten Layer — und der letzte gewinnt.
Das ist gleichzeitig sehr praktisch und sehr gefährlich:
- **Praktisch**, weil du in einer Bestandscodebasis einfach anfangen kannst, Teile in Layer zu ziehen, ohne dass der noch ungelayerte Rest plötzlich schwächer wird. Migration ohne Big Bang.
- **Gefährlich**, weil jede Datei, die du *vergisst* zu layern, automatisch die höchste Priorität bekommt. Ein einziges vergessenes `` auf ein Fremd-Stylesheet hebelt deine ganze Layer-Architektur aus. Dazu unten mehr.
### Regel 4: `!important` dreht die Reihenfolge um
Das ist die Regel, die am häufigsten für Verwirrung sorgt, und sie ist völlig konsistent gedacht: `!important` bedeutet in CSS seit jeher „Umkehrung der normalen Machtverhältnisse" — deshalb schlagen `!important`-Regeln des Nutzers die des Autors. Bei Layern gilt dasselbe Prinzip.
```css
@layer a, b;
@layer a { #box { color: red !important; } }
@layer b { #box { color: blue !important; } }
```
**Gemessen: rot.** Bei `!important` gewinnt der **frühere** Layer.
Und die Fortsetzung davon:
```css
@layer irgendwas { #box { color: blue !important; } }
#box { color: red !important; } /* ungelayert */
```
**Gemessen: blau.** Ungelayerte `!important`-Regeln sind unter allen Autoren-`!important`-Regeln die **schwächsten** — spiegelbildlich zu Regel 3.
Merke: Ein Layer, den du weit vorne einsortierst, ist bei normalen Deklarationen der schwächste — und bei `!important` der stärkste. Diese Doppelrolle ist der Hebel für das Bootstrap-Rezept weiter unten.
### Regel 5: Verschachtelte Layer verhalten sich wie ihr Elternteil im Kleinen
```css
@layer c.card { #box { color: red; } }
@layer c.button { #box { color: green; } }
```
**Gemessen: grün.** Innerhalb von `c` gilt dieselbe Logik: später deklariert gewinnt.
Und der Sonderfall, den man einmal gesehen haben muss:
```css
@layer c;
@layer c.child { #box { color: red; } }
@layer c { #box { color: green; } } /* direkt in c, nicht in einem Kind */
```
**Gemessen: grün.** Regeln, die *direkt* im Elternteil liegen, gelten als impliziter letzter Unter-Layer — sie schlagen also alle benannten Kinder. Mit `!important` kehrt sich auch das um (dann gewinnt das erste Kind).
### Regel 6: `revert-layer` gibt Kontrolle an die vorherige Schicht zurück
```css
@layer basis, thema;
@layer basis { .btn { color: green; } }
@layer thema { .btn { color: red; }
.btn.plain { color: revert-layer; } }
```
**Gemessen: grün** für `.btn.plain`. Der Wert wird nicht auf den Initialwert zurückgesetzt (das wäre `unset` beziehungsweise `initial`), sondern auf den, den die *vorherige* Schicht gesetzt hätte.
Zwei Randfälle, beide gemessen:
- **`revert-layer` im untersten Layer** fällt durch bis ins Browser-Stylesheet. Ein `` mit `color: revert-layer` im einzigen Layer wurde zu `rgb(0, 0, 238)` — dem Standard-Linkblau des Browsers.
- **`revert-layer` in ungelayertem CSS** fällt auf die Schicht darunter zurück — also auf den letzten expliziten Layer, der die Eigenschaft **überhaupt setzt**, nicht ins Browser-Stylesheet. Getestet mit zwei Layern `l1` (rot) und `l2` (grün) plus einer ungelayerten Regel `color: revert-layer` — Ergebnis: **grün**, also der Wert aus `l2`. Setzt `l2` die Eigenschaft nicht, fällt es weiter auf `l1` durch; setzt sie kein Layer, landet man doch beim Browser-Stylesheet.
Der zweite Punkt ist bemerkenswert, weil verbreitete Zusammenfassungen hier etwas anderes behaupten (nämlich pauschal Rückfall auf das Browser-Stylesheet). Das gemessene Verhalten deckt sich mit der Spezifikation: Ungelayertes CSS *ist* der implizite letzte Layer, und „vorheriger Layer" ist entsprechend der letzte benannte. Es ist auch kein Chromium-Sonderweg — die Web-Platform-Tests decken genau diesen Fall ab (`css/css-cascade/revert-layer-002.html`), und er besteht in Chrome, Firefox und Safari.
Und eine Grenze: `revert-layer` ist eine normale Deklaration. Gegen ein `!important` aus einem anderen Layer kommt sie nicht an — auch das gemessen.
### Regel 7: Ein Layer, der nur deklariert wurde, hält seinen Platz
```css
@layer erst, zweit;
@layer zweit { #box { color: green; } }
@layer erst { #box { color: red; } }
```
**Gemessen: grün.** Die Deklarationszeile hat beide Layer angelegt; dass `zweit` textlich zuerst befüllt wird, spielt keine Rolle.
Ein Detail für Fortgeschrittene: Layer, die *innerhalb* einer `@media`-Bedingung angelegt werden, entstehen nur, wenn die Bedingung zutrifft. Damit hängt die Layer-Reihenfolge plötzlich vom Viewport ab. Das ist selten gewollt — deklariere die Reihenfolge unbedingt außerhalb aller Bedingungsblöcke.
### Regel 8: Animationen und Transitions stehen über allem
```css
@layer alles { #box { color: red; } }
#box { animation: farbe 100s step-end forwards; }
@keyframes farbe { from { color: green; } to { color: green; } }
```
**Gemessen: grün.** Eine laufende Animation schlägt jede normale Deklaration, gelayert oder nicht; eine laufende Transition schlägt sogar `!important`. Das ist kein Layer-Spezifikum, aber es erklärt einen Teil der Fälle, in denen `@layer` scheinbar „nicht wirkt".
## Praxis 1: Eine gewachsene Website auf Layer umstellen
Der Fall, den ich am besten belegen kann, ist die Hauptseite [jpkc.com](https://www.jpkc.com/). Deren CSS ist über Jahre gewachsen, hat einen Bootstrap-4-Erbteil im Reset und wird als **eine einzige Datei inline in jede Seite** geschrieben (rund 1.900 Zeilen, minifiziert per `lightningcss`). Ein klassischer Kandidat also: viel Bestand, keine Lust auf Neuschreiben.
Die Umstellung war ein einzelner Commit und bestand aus genau zwei Handgriffen.
**Erstens** die Reihenfolge festlegen, direkt nach den Custom Properties:
```css
@layer reset, base, components, utilities, responsive;
```
**Zweitens** die bestehenden Abschnitte in Blöcke wickeln — ohne eine einzige Regel zu verschieben:
| Layer | Was hineinkam |
|---|---|
| `reset` | `html`, `body`, `:target`, Scrollbars, die `:focus-visible`-Grundlinie |
| `base` | Typografie, Links, Code, Medien, Tabellen, Formulare, `::selection` |
| `components` | Buttons, Dropdown, SVG-Icons, Header, Hauptbereich, Navigation, ``, Footer |
| `utilities` | `.visually-hidden`, Spacer, `.box`, Verzeichnisbaum-Liste, Light-Toggle |
| `responsive` | sämtliche `@media`-Blöcke — Breakpoints, `inverted-colors`, Print |
Die Datei behielt ihre Abschnittsreihenfolge. Weil sich mehrere Blöcke desselben Namens zusammenführen (Regel: Layer-Block), steht `@layer components { … }` an mehreren Stellen der Datei — das ist beabsichtigt und kein Fehler.
Drei Entscheidungen daran sind übertragbar:
**Die Tokens bleiben ungelayert.** Der `:root`-Block mit allen Custom Properties steht *vor* der Layer-Deklaration und außerhalb jedes Layers. (Custom Properties sind CSS-Variablen: mit `--name: wert` definiert, mit `var(--name)` gelesen; sie vererben sich an Nachfahren. `:root` ist die Pseudo-Klasse für das Wurzelelement, in HTML also ``.) Damit haben die Design-Tokens unbedingte Priorität und können von keiner Komponente versehentlich überschrieben werden. Ob das die richtige Wahl ist, hängt vom Projekt ab — das Design-Token-Kapitel weiter unten diskutiert die Gegenposition.
**`responsive` als eigener Layer ist der eigentliche Gewinn.** Vorher galt: Ein `@media`-Block überschreibt eine Komponentenregel nur, wenn er im Quelltext weiter unten steht *und* mindestens dieselbe Spezifität hat. Beides musste man beim Bearbeiten im Kopf behalten. Jetzt gewinnt der Media-Block immer, weil sein Layer der letzte ist — auch mit einem simpleren Selektor. Genau das war zuvor die Fehlerquelle Nummer eins beim Anfassen alter Breakpoints.
**Die `!important`-Umkehr wurde bewusst protokolliert.** In der neuen Ordnung ist das `!important` in `.visually-hidden` (Layer `utilities`) *stärker* als jedes `!important` im Print-Stylesheet (Layer `responsive`). Aktuell gibt es keine Kollision, weil beide unterschiedliche Eigenschaften setzen — aber genau solche Konstellationen muss man beim Umstellen einmal durchsehen und notieren. Wer viele `!important` im Bestand hat, sollte die vor der Umstellung inventarisieren.
**Und die Kosten?** Exakt +83 Byte pro Seite nach der Minifizierung — auf jeder Seite dieselben 83 Byte, weil es schlicht die At-Rule-Zeilen sind. Bei einer Datei, die vollständig inline in jedes HTML-Dokument geht, sind das je nach Seitenlänge 0,06 % (Startseite) bis 0,18 % (kürzeste Unterseite). Für externe Stylesheets ist der Effekt durch Kompression noch kleiner. `@layer` kostet praktisch nichts.
Ein Detail zum Toolchain-Vertrauen: `lightningcss` **erhält** die Layer-Semantik beim Minifizieren, es entfernt die At-Rules nicht. Ein Minifier schreibt CSS auf minimale Größe um — benachbarte Regeln zusammenführen, Langform zu Kurzform verdichten —, und `lightningcss` ist so ein Werkzeug, geschrieben in Rust. Das ist nicht selbstverständlich und sollte bei jedem Build-Tool einmal am Output geprüft werden — ein Minifier, der `@layer`-Blöcke „wegoptimiert", kehrt die gesamte Kaskade um.
### Das Migrations-Rezept in Kurzform
1. `@layer`-Reihenfolge ganz oben deklarieren.
2. Bestehende Abschnitte *an Ort und Stelle* einwickeln, nichts verschieben.
3. Custom Properties bewusst platzieren (drinnen oder draußen — aber entschieden).
4. Alle `!important` im Projekt auflisten und die Umkehr gegenprüfen.
5. Bauen, minifizierten Output auf erhaltene `@layer`-Blöcke prüfen.
6. Visuell diffen. Wenn die Reihenfolge korrekt gewählt ist, ändert sich nichts — genau das ist das Ziel.
## Praxis 2: Bootstrap in einen eigenen Layer
Der eigentliche Star-Anwendungsfall von `@layer` ist Fremd-CSS. Nimm Bootstrap als Beispiel, weil es das verbreitetste ist und weil sein Verhalten sehr gut messbar ist.
Ich habe die aktuelle Distribution heruntergeladen und ausgezählt — Bootstrap 5.3.8, `dist/css/bootstrap.css`, rund 280 KB:
- **`@layer`-Vorkommen: 0.** Bootstrap 5 liefert keine Cascade Layers aus. Alles landet ungelayert — und damit nach Regel 3 *über* allem, was du selbst in Layer packst.
- **`!important`-Vorkommen: 1.716.** Der Löwenanteil kommt aus der Utility-API — einem Sass-Generator, der aus einer Konfigurations-Map Klassen wie `.m-1` oder `.text-danger` erzeugt. Eine **Utility-Klasse** hat genau einen Zweck und wird im Markup mit anderen kombiniert; `.mt-0` setzt `margin-top: 0`, `.text-center` zentriert den Text. Jede erzeugte Utility-Klasse trägt per Voreinstellung `!important`, damit sie ihre Komponente sicher überschreibt.
Diese beiden Zahlen beschreiben das Problem präzise. Wer Bootstrap anpassen will, kämpft nicht gegen dessen Spezifität, sondern gegen dessen Position in der Kaskade und gegen 1.716 `!important`.
### Schritt 1: Das Framework in einen frühen Layer
```css
@layer framework, app;
@import url("bootstrap.css") layer(framework);
@layer app {
.btn {
border-radius: 0; /* gewinnt — ohne !important, ohne Selektor-Aufblähung */
}
}
```
**Gemessen: funktioniert.** Eine einzelne Klasse in `app` schlägt Bootstraps Komponentenregeln, egal wie diese aufgebaut sind. Der gesamte Werkzeugkasten aus „noch eine Klasse davor" und „`.btn.btn.btn`" entfällt ersatzlos.
Das ist der Punkt, an dem das Arbeiten mit einem Framework qualitativ kippt: Du musst dessen Selektoren nicht mehr kennen, um sie zu überschreiben. Du musst nur wissen, dass dein Layer später kommt.
### Schritt 2: Die `!important`-Falle
Jetzt der Haken, den die meisten Anleitungen auslassen. Nach Regel 4 kehrt sich die Layer-Reihenfolge bei `!important` um. Bootstrap liegt in `framework`, also im *frühesten* Layer. Damit gilt:
**Bootstraps 1.716 `!important`-Deklarationen sind in dieser Anordnung stärker als deine eigenen `!important`-Deklarationen in `app`.**
Getestet mit Bootstraps `.text-danger { color: … !important }` gegen ein `!important` im späteren `app`-Layer: **Bootstrap gewinnt.** Das ist kein Bug, sondern die logische Folge von Regel 4 — aber es überrascht zuverlässig jeden, der es zum ersten Mal trifft.
### Schritt 3: Der Override-Layer
Die Lösung ist ein Layer, der **noch vor** dem Framework liegt und ausschließlich für `!important`-Gegenwehr da ist:
```css
@layer bs-overrides, bootstrap, app;
@import url("bootstrap.css") layer(bootstrap);
@layer bs-overrides {
/* Nur !important-Regeln, die Bootstrap-Utilities aushebeln sollen. */
.text-danger { color: var(--brand-danger) !important; }
}
@layer app {
/* Alles Normale — schlägt Bootstrap ohne !important. */
.btn { background: var(--brand); }
}
```
**Gemessen: beides funktioniert.** `bs-overrides` gewinnt das `!important`-Duell (früherer Layer), `app` gewinnt das normale Duell (späterer Layer). Ein Layer für jede Richtung.
Das wirkt zunächst wie ein Kunstgriff, ist aber sauber begründbar: Du hast zwei verschiedene Absichten — „ich möchte den Normalfall ergänzen" und „ich möchte eine Notbremse des Frameworks aushebeln" — und in einer Kaskade mit Umkehr brauchen zwei Absichten zwei Plätze.
**Die bessere Lösung, wenn du Bootstrap selbst kompilierst:** Schalte die `!important` an den Utilities einfach ab. Bootstrap hat dafür eine Sass-Variable — Sass ist ein CSS-Präprozessor mit eigener Sprache (Variablen mit `$name`, Mixins, Verschachtelung), den ein Build-Schritt zu CSS kompiliert; SCSS ist dessen CSS-nahe Schreibweise:
```scss
$enable-important-utilities: false;
@import "bootstrap/scss/bootstrap";
```
Ohne `!important` an den Utilities entfällt das gesamte zweite Layer-Problem, und die reine Layer-Reihenfolge reicht. Diese Variable gibt es seit Bootstrap 5.0 und sie steht in `scss/_variables.scss` auf `true !default`.
### Der Sass-Fallstrick
Wer Bootstrap per Sass einbindet, stößt auf eine echte Werkzeug-Grenze: **`@use` darf in Sass nicht innerhalb eines Blocks stehen.** (`@use` lädt eine Sass-Datei als Modul, dessen Variablen, Mixins und Funktionen unter einem Namensraum bereitstehen; `@forward` reicht sie weiter. Beide ersetzen das abgekündigte `@import`.) Das hier ist also kein gültiges Sass:
```scss
@layer bootstrap {
@use "bootstrap/scss/bootstrap"; /* Fehler: @use muss auf oberster Ebene stehen */
}
```
Ein `layer()`-Argument für `@use` und `@forward` war 2022 zwar vorgeschlagen, wurde aber binnen weniger Tage abgelehnt — mit dem Hinweis, dass Sass dafür bereits ein Werkzeug hat. Genau das ist der saubere Weg:
**`meta.load-css()` lädt ein Sass-Modul dort, wo du gerade stehst** — also auch innerhalb eines `@layer`-Blocks:
```scss
@use "sass:meta";
@layer bootstrap {
@include meta.load-css("bootstrap/scss/bootstrap");
}
```
Getestet mit Dart Sass 1.102.0: Das kompiliert zu `@layer bootstrap { … }` mit dem vollständigen Framework-CSS darin — und ohne Deprecation-Warnung. Wichtig ist der Unterschied zu `@use`: `meta.load-css()` gibt nur das **CSS** aus, es stellt dir Variablen, Mixins und Funktionen des Moduls **nicht** zur Verfügung. Die lädst du weiterhin oben per `@use` — und genau diese Arbeitsteilung ist der Punkt.
Damit hast du drei gangbare Wege, in dieser Reihenfolge:
1. **`meta.load-css()` innerhalb des Layers.** Der offizielle Weg, kein Verfallsdatum, keine zusätzliche Datei. Erste Wahl, wenn das Framework ohnehin durch deine Sass-Pipeline läuft.
2. **Framework separat kompilieren.** Bootstrap zu einer eigenen `.css`-Datei bauen und per `@import url(…) layer(bootstrap)` aus einem schlanken CSS-Einstiegspunkt holen. Sauberste Trennung, unabhängig von Sass — sinnvoll, wenn du das Framework gar nicht anpasst.
3. **Nach dem Build umwickeln.** Ein PostCSS-Schritt legt den kompletten kompilierten Framework-Output in einen Layer. Robust und toolchain-unabhängig, kostet aber einen zusätzlichen Build-Schritt.
Das früher übliche verschachtelte `@import` innerhalb `@layer { }` funktioniert weiterhin, wirft aber eine Deprecation-Warnung — `@import` wird in Dart Sass 3.0 entfernt. Für neuen Code also nicht mehr verwenden.
### Der ``-Fallstrick
Und jetzt der Fehler, der eine ganze Layer-Architektur lautlos wertlos macht.
**Ein `` kann heute keinem Layer zugewiesen werden.** Es gibt keinen `layer`-Attributwert für ``. Der entsprechende Vorschlag liegt seit Jahren bei der CSS Working Group, ist aber in keinem Browser umgesetzt.
Die Konsequenz ist nach Regel 3 hart:
```html
```
```css
/* fremd.css */
#box { color: red; } /* Spezifität 0-1-0-0 */
```
**Gemessen: rot.** Die schwächere Regel aus dem verlinkten Stylesheet gewinnt, weil sie ungelayert ist. Deine sorgfältig gebaute Layer-Ordnung ist gegen sie machtlos.
Der Workaround ist ein Zwischen-Stylesheet: Eine winzige CSS-Datei, die nichts tut, außer die eigentlichen Dateien in Layer zu importieren.
```css
/* main.css — die einzige Datei, die per geladen wird */
@layer reset, framework, base, components, utilities;
@import url("reset.css") layer(reset);
@import url("bootstrap.css") layer(framework);
@import url("base.css") layer(base);
@import url("components.css") layer(components);
@import url("utilities.css") layer(utilities);
```
Damit hast du aber ein Performance-Problem eingetauscht: `@import`-Ketten werden **seriell** aufgelöst. Der Browser muss `main.css` vollständig laden und parsen, bevor er überhaupt weiß, dass er `bootstrap.css` braucht — und CSS blockiert das Rendering, zeigt also nichts an, bevor es geladen und geparst ist (sonst blitzte kurz ungestyltes HTML auf). Bei fünf Importen wartest du auf mindestens zwei volle Roundtrips — ein Roundtrip ist ein kompletter Weg Anfrage-Antwort zum Server und zurück.
Die praktikable Antwort für Produktion: **Bündeln zur Build-Zeit.** Dein Bundler (esbuild, Vite, Lightning CSS, PostCSS — Letzteres kein Präprozessor mit eigener Sprache wie Sass, sondern ein Werkzeug, das CSS im Build über JavaScript-Plugins umschreibt) löst die `@import`-Anweisungen auf und schreibt die `@layer`-Blöcke direkt in eine Datei. Du behältst die saubere Quellstruktur, der Browser bekommt eine einzige Anfrage. Wer `@import` zur Laufzeit stehen lässt, sollte die betroffenen Dateien zumindest per `` anstoßen.
## Praxis 3: Tailwind CSS v4 — die Layer sind schon da
Wer Tailwind in Version 4 einsetzt, arbeitet bereits mit echten Cascade Layers, ob er will oder nicht. Tailwind v3 hatte ein `@layer`-Konstrukt, das nur *aussah* wie die CSS-At-Rule: Es war eine PostCSS-Direktive, die zur Build-Zeit ausgewertet und wieder entfernt wurde. Version 4 nutzt native Layer und schreibt sie in den Output.
Das lässt sich am Build dieser Seite hier direkt zeigen. Der Kopf der generierten `main.css` (Tailwind 4.3.0):
```css
/*! tailwindcss v4.3.0 | MIT License | https://tailwindcss.com */
@layer properties { … }
@layer theme { … }
@layer base { … }
@layer components { … }
@layer utilities { … }
```
Fünf Layer in dieser Reihenfolge. Der erste davon ist bedarfsabhängig: `properties` erscheint nur, wenn die erzeugten Utilities tatsächlich registrierte Custom Properties brauchen — ein Minimal-Build ohne solche Klassen gibt nur `theme, base, components, utilities` aus. Was das für deinen eigenen Code bedeutet:
**Eigenes CSS ohne Layer schlägt alle Tailwind-Utilities.** Das folgt aus Regel 3 und ist die häufigste Ursache für „meine Utility-Klasse wirkt nicht". Wenn du eine eigene Komponentendatei per `@import` neben Tailwind lädst und sie in keinem Layer liegt, gewinnt sie gegen `@layer utilities` — und damit gegen `p-4`, `text-center` und alles andere.
Die Lösung ist, eigenes CSS ebenfalls einzuordnen:
```css
@import "tailwindcss";
/* Eigene Komponenten unterhalb der Utilities einsortieren, damit
Utility-Klassen im Markup weiterhin das letzte Wort haben. */
@layer components {
.prose-card {
border-radius: 0.75rem;
padding: 1.5rem;
}
}
```
**Für neue Utilities gibt es einen eigenen Weg.** Tailwind v4 bringt die Direktive `@utility` mit, die eine Klasse als echte Utility registriert — du schreibst sie direkt in deine CSS-Datei (`@utility tab-4 { tab-size: 4; }`). Dazu gehören Varianten-Unterstützung (die Präfixe `hover:` und `md:`, die eine Utility an einen Zustand oder einen Breakpoint binden) und die korrekte Einsortierung in den `utilities`-Layer. Ein handgeschriebenes `@layer utilities { … }` bekommt das nicht mit.
**Und ein Framework über dem Framework?** Wenn du Tailwind mit einem weiteren Fremd-Stylesheet kombinierst, kannst du die gesamte Tailwind-Ausgabe in einen übergeordneten Layer verschieben, indem du den Import layerst:
```css
@layer vendor, tw, app;
@import "tailwindcss" layer(tw);
```
Tailwinds eigene Layer werden dadurch zu `tw.theme`, `tw.base`, `tw.components` und `tw.utilities` — die interne Reihenfolge bleibt erhalten, der Block rückt als Ganzes zwischen `vendor` und `app`. Das ist die verschachtelte Namensraum-Kapselung aus dem Syntax-Kapitel in ihrer nützlichsten Form.
**Eine Ausnahme gibt es dabei**, und sie ist am realen Build nachgemessen: `properties` entkommt der Verschachtelung. Der Layer bleibt auf oberster Ebene und wird sogar noch vor `vendor` deklariert — er ist damit der schwächste im ganzen Dokument. Das ist unkritisch, weil er nur Ausgangswerte liefert, aber es heißt: Von den fünf Layern wandern nur vier in den Namensraum.
Womit auch geklärt wäre, was `properties` überhaupt tut: Er enthält einen `@supports`-Block, der registrierte Custom Properties dort nachbildet, wo der Browser sie noch nicht kennt. Die Bedingung zielt auf zwei Engines gleichzeitig — ältere Safari- **und** ältere Firefox-Versionen (vor 128).
## Praxis 4: Fremd-Widgets, Embeds und Legacy-Code
Der dritte klassische Anwendungsfall ist alles, was du nicht kontrollierst und nicht anfassen willst: eingebettete Buchungs-Widgets, Consent-Banner, Chat-Fenster, das CSS eines alten Bereichs, den niemand mehr versteht.
Der Reflex ist hier der **anonyme Layer** — und genau daran lässt sich eine Falle zeigen, in die man erstaunlich leicht tappt. Dieses Beispiel tut **nicht**, was es verspricht:
```css
@layer app; /* ❌ app ist jetzt der ERSTE Layer */
@import url("widget.css") layer; /* ❌ der anonyme Layer entsteht DANACH */
```
Gemessen: Das Widget gewinnt. Die Erklärung ist Regel 2 — die Reihenfolge steht bei der ersten Erwähnung fest. `@layer app;` erwähnt `app` zuerst und macht es damit zum schwächsten Layer; der anonyme Layer des Imports entsteht danach und ist folglich stärker. Anonyme Layer haben genau diese Eigenheit: Weil sie keinen Namen tragen, kannst du sie in **keiner** Reihenfolgezeile vorziehen. Ihre Position ergibt sich allein daraus, wo der Import steht.
Richtig ist deshalb ein **benannter** Vendor-Layer, der in der Reihenfolgezeile ganz vorne steht:
```css
@layer widget, app; /* Fremdcode zuerst = schwächster Layer */
@import url("widget.css") layer(widget);
@layer app {
/* dein Code — gewinnt jede normale Auseinandersetzung */
}
```
**Gemessen: funktioniert.** Du legst den Fremdcode in einen Layer, der ganz vorne steht, und musst ihn danach nie wieder erwähnen. Niemand erweitert ihn versehentlich, und dein eigenes CSS gewinnt jede normale Auseinandersetzung.
Wenn der Layer wirklich anonym bleiben soll, muss der Import **vor** allem Eigenen stehen — dann stimmt die Reihenfolge, aber du gibst die Möglichkeit auf, sie später explizit zu dokumentieren. In der Praxis ist der benannte Layer fast immer die bessere Wahl.
Für Legacy-Code im eigenen Haus ist ein benannter Layer besser:
```css
@layer legacy, modern;
@layer legacy {
/* Der alte Bereich, unverändert hineinkopiert. */
}
```
Der Effekt ist ein technischer Schuldenschnitt: Alles in `legacy` verliert automatisch gegen alles Neue. Du kannst alten Code liegenlassen, statt ihn zu entschärfen — und Stück für Stück herausziehen, ohne dass sich zwischendurch die Prioritäten verschieben.
## Web Components: was Layer können — und was nicht
Kurz zum Vokabular, bevor es losgeht: **Web Components** ist der Sammelbegriff für eigene HTML-Elemente mit gekapseltem Innenleben. Ein **Custom Element** ist so ein selbst definiertes Element (Name mit Bindestrich, per `customElements.define()` registriert); an ihm hängt ein **Shadow DOM** — ein eigener, abgeschotteter DOM-Baum, dessen Styles gescopt sind und in den normale Dokument-Selektoren nicht hineingreifen.
Hier wird es interessant, denn die verbreitete Erwartung ist falsch. Wer `@layer` als „Prioritätssystem für CSS" verstanden hat, nimmt an, dass sich damit auch die Grenze zwischen Seite und Web Component regeln lässt. Das geht nicht — und zwar aus einem sehr klaren Grund.
### Der Kapselungskontext steht über den Layern
Erinnere dich an die Sortierreihenfolge aus dem zweiten Kapitel: **Kapselungskontext** steht auf Platz 2, **Layer** erst auf Platz 4. Kapselungskontext heißt schlicht: aus welchem Baum die Deklaration stammt — Dokument oder Shadow-Baum. Der Browser prüft also zuerst, aus welchem Baum eine Deklaration stammt, und kommt zur Layer-Frage überhaupt nur, wenn beide aus demselben Baum kommen.
Die Regel für den Kapselungskontext lautet:
> Bei **konkurrierenden** Deklarationen für dasselbe Element gewinnt bei **normalen** Deklarationen der **äußere** Baum, bei **`!important`** der **innere**.
Das Wort „konkurrierend" trägt hier Gewicht. Die Regel greift nur, wo überhaupt zwei Deklarationen um dasselbe Element streiten — also bei `:host`, `::part()` und `::slotted()`. Überall dort, wo das Dokument die Elemente im Shadow-Baum gar nicht selektieren kann, gewinnt die Komponente ohnehin, und ein geerbter Wert wird von jeder Shadow-Regel geschlagen.
Gemessen an einem Custom Element mit offenem Shadow Root:
```html
…
```
```js
shadow.innerHTML = ``;
```
**Gemessen: grün.** Die Dokumentregel gewinnt — obwohl die Shadow-Regel im späteren Layer ihres Baums liegt. Der Layer wurde gar nicht erst befragt.
Und die Gegenprobe mit `!important`:
```html
```
```js
shadow.innerHTML = ``;
```
**Gemessen: blau.** Jetzt gewinnt der innere Baum.
### Layer-Namen überqueren keine Shadow-Grenze
Der zweite wichtige Punkt: **Jeder Shadow-Baum hat seine eigene, völlig unabhängige Layer-Reihenfolge.** Ein `@layer components` im Dokument und ein `@layer components` im Shadow Root sind zwei verschiedene Dinge, die nichts voneinander wissen.
Gemessen: Deklariert das Dokument `@layer b, a;` und der Shadow-Baum erwähnt ohne eigene Reihenfolgezeile erst `a` und dann `b`, so gilt im Inneren die dortige Erstnennung — die Reihenfolgezeile des Dokuments bleibt wirkungslos.
Das ist konsistent mit dem Zweck von Shadow DOM: Kapselung ist genau die Zusage, dass äußere Struktur innen nichts bedeutet. Zwei Präzisierungen gehören aber dazu, weil die Kurzfassung „Layer und Shadow DOM haben nichts miteinander zu tun" in beide Richtungen zu grob ist.
**Erstens: Ein globales `@layer reset` erreicht Shadow-Bäume teilweise sehr wohl.** Selektor-Gebundenes bleibt draußen — `* { box-sizing: border-box }` aus dem Dokument wirkt im Shadow-Baum nicht. **Vererbbare** Eigenschaften fließen dagegen wie eh und je hinein: Ein `font-family: monospace` und ein `letter-spacing: 3px` aus dem Dokument-Reset waren im Shadow-Baum messbar wirksam. Da ein realer Reset aus beidem besteht, kommt sein Typografie-Teil vollständig an.
**Zweitens: Eine Layer-API nach außen ist möglich — aber nur über den Baum, nicht über die Dokumentgrenze.** Solange dein CSS im Dokument liegt, kannst du der Komponente keinen Layer unterschieben; der Kapselungskontext entscheidet vorher. Landet dein Stylesheet dagegen *im* Shadow-Baum — weil die Komponente ein `CSSStyleSheet` entgegennimmt und adoptiert, oder weil ihr Shadow Root offen ist und du ein `