Wenn eine Farbe nicht greift, obwohl die Regel eindeutig im Stylesheet steht, liegt das fast nie am Browser. Irgendeine andere Deklaration gewinnt, weil sie aus einem stärkeren Ursprung kommt, in einer höheren Ebene liegt, spezifischer ist oder später folgt. Wer diese Reihenfolge kennt, braucht kein !important mehr als Notlösung und findet Konflikte in den Entwicklerwerkzeugen in Sekunden.
Die Sortierkriterien der Kaskade
Schon die CSS2-Empfehlung von 1998 beschrieb die Kaskade in wenigen Schritten: Herkunft und Gewicht, dann Spezifität, dann Reihenfolge. Heute legt CSS Cascading and Inheritance Level 5 (Candidate Recommendation vom 13. Januar 2022) die Reihenfolge fest. Der Browser vergleicht zwei Deklarationen für dieselbe Eigenschaft nacheinander nach diesen Kriterien und hört beim ersten Unterschied auf:
- Ursprung und Wichtigkeit (
!important) - Kontext, etwa Shadow DOM bei Webkomponenten
- direkt am Element hängende Stile (Attribut
style) - Cascade Layers (
@layer) - Spezifität des Selektors
- Nähe der Scope-Wurzel bei
@scope(aus dem Entwurf Level 6) - Reihenfolge im Quelltext: die spätere Deklaration gewinnt
Wichtig ist die Rangfolge: Spezifität entscheidet erst, wenn Ursprung, Kontext und Ebene gleich sind. Ein Selektor mit drei IDs verliert gegen eine schlichte Klasse, wenn diese in einer späteren Ebene steht.
Ursprünge: Browser, Nutzer, Autor und !important
Jede Deklaration stammt aus einem Ursprung. Das User-Agent-Stylesheet des Browsers sorgt dafür, dass h1 groß und fett ist und Links unterstrichen sind. Nutzerstile kommen von Menschen, die etwa per Erweiterung oder Browsereinstellung eigene Farben und Schriftgrößen erzwingen. Autorenstile sind das CSS der Website. Hinzu kommen Animationen und Übergänge als eigene Ursprünge. Die vollständige Rangfolge laut Spezifikation, von stark nach schwach:
| Rang | Ursprung |
|---|---|
| 1 | laufende Transitions |
| 2 | User-Agent mit !important |
| 3 | Nutzer mit !important |
| 4 | Autor mit !important |
| 5 | Animationen (@keyframes) |
| 6 | Autor normal |
| 7 | Nutzer normal |
| 8 | User-Agent normal |
Bei normalen Deklarationen schlägt also der Autor den Nutzer, bei !important dreht sich das um. Diese Umkehr war 1998 eine bewusste Änderung gegenüber CSS1, in dem Autoren-!important noch gewann: Wer aus Gründen der Barrierefreiheit große Schrift oder hohe Kontraste braucht, soll sich gegen jede Website durchsetzen können. Für Autoren folgt daraus eine einfache Regel: !important gehört in Hilfsklassen wie .visually-hidden, die nie überschrieben werden sollen, nicht in den Alltag.
Spezifität berechnen
Spezifität besteht aus drei Zählern, geschrieben als ID-Klasse-Typ. Die erste Spalte zählt ID-Selektoren, die zweite Klassen, Attributselektoren und Pseudoklassen, die dritte Typselektoren und Pseudoelemente. Verglichen wird von links nach rechts; ein einziger höherer Wert weiter links entscheidet, egal wie groß die Zahlen rechts davon sind. Elf Klassen schlagen also keine ID. Der Universalselektor *, Kombinatoren und :where() zählen nichts; :is(), :not() und :has() übernehmen die Spezifität ihres spezifischsten Arguments.
| Selektor | ID | Klasse | Typ |
|---|---|---|---|
* | 0 | 0 | 0 |
ul li | 0 | 0 | 2 |
.nav a | 0 | 1 | 1 |
a:hover | 0 | 1 | 1 |
input[type='email']:focus | 0 | 2 | 1 |
nav > ul li.aktiv::before | 0 | 1 | 4 |
.btn.btn | 0 | 2 | 0 |
#kopf .logo img | 1 | 1 | 1 |
:is(#kopf, .fuss) a | 1 | 0 | 1 |
:where(#kopf) a | 0 | 0 | 1 |
:not(.intern) a | 0 | 1 | 1 |
Zwei Details überraschen oft. Die Nähe im DOM spielt keine Rolle: body h1 und html h1 sind gleich spezifisch, es gewinnt die spätere Regel. Und ein Attribut style am Element steht über allen Selektoren, weil es als eigenes Kriterium vor der Spezifität geprüft wird. Im CSS2-Text von 1998 wurden Pseudoelemente übrigens noch gar nicht mitgezählt; heute zählen sie wie Typselektoren. Mehr zu den einzelnen Selektortypen steht im Beitrag über CSS-Selektoren.
Cascade Layers mit @layer
Ebenen lösen das Hauptproblem großer Projekte: Ein Reset, ein Framework und eigene Komponenten konkurrieren über Spezifität, und am Ende wird hochgerüstet. Mit @layer legt man die Rangfolge vorab fest; Spezifität zählt dann nur noch innerhalb einer Ebene. @layer ist laut MDN seit März 2022 in allen großen Browsern verfügbar.
@layer reset, framework, komponenten;
@import url('framework.css') layer(framework);
@layer framework {
#inhalt a { color: navy; } /* 1-0-1, aber frühere Ebene */
}
@layer komponenten {
.btn { color: white; } /* 0-1-0, gewinnt trotzdem */
}
a { text-decoration-thickness: 2px; } /* ohne Ebene: schlägt alle Ebenen */Zwei Regeln muss man kennen. Stile außerhalb jeder Ebene stehen über allen benannten Ebenen. Und bei !important kehrt sich die Ebenenfolge um: Ein wichtiges reset schlägt dann ein wichtiges komponenten, und Ebenen schlagen wichtige Stile ohne Ebene. Die Empfehlung: Fremd-CSS konsequent in Ebenen packen, eigene Komponenten in die letzte Ebene, und !important innerhalb von Ebenen meiden.
@scope und Nähe als Entscheidungskriterium
@scope begrenzt Regeln auf einen DOM-Bereich, optional mit Untergrenze: @scope (.artikel) to (figure) { img { … } } trifft Bilder im Artikel, aber nicht die in Abbildungen. Selektoren darin bekommen keine zusätzliche Spezifität. Kommen zwei Scopes in Konflikt, gewinnt bei gleicher Spezifität der mit der näheren Wurzel, also das innere Thema bei verschachtelten hellen und dunklen Bereichen. Unterstützung laut Can I use: Chrome und Edge ab 118, Safari ab 17.4, Firefox ab 146; MDN führt @scope als Baseline 2026, also neu verfügbar. Für Projekte mit älteren Zielbrowsern sollte es deshalb vorerst nur ergänzend eingesetzt werden.
Vererbung und die Schlüsselwörter inherit bis revert-layer
Manche Eigenschaften werden an Kindelemente weitergegeben, andere nicht. Schrift und Farbe vererben sich (color, font-family, line-height), Rahmen, Abstände und Hintergründe nicht. MDN nennt auf jeder Eigenschaftsseite den Eintrag „Inherited: yes/no“. Vererbt wird immer der berechnete Wert des Elternelements, und jede Regel, die das Kind direkt trifft, schlägt den geerbten Wert, egal wie spezifisch die Elternregel war.
| Schlüsselwort | Ergebnis | Typischer Einsatz |
|---|---|---|
inherit | Wert des Elternelements | font: inherit für Buttons und Eingabefelder |
initial | Anfangswert aus der Spezifikation | selten sinnvoll, display: initial ergibt inline |
unset | wie inherit bei vererbten, sonst wie initial | mit all: unset Elemente komplett neutralisieren |
revert | zurück auf den vorherigen Ursprung, meist das Browser-Stylesheet | Standardaussehen einer Liste zurückholen |
revert-layer | zurück auf die darunterliegende Ebene | Ausnahme von einer Komponentenregel |
Der Unterschied zwischen initial und revert wird oft unterschätzt: initial holt den Wert aus der Spezifikation, nicht den des Browsers. Für display ist das inline, auch bei einem div. Wer das Browser-Standardaussehen will, braucht revert.
Vom deklarierten zum tatsächlichen Wert
Die Spezifikation unterscheidet mehrere Stufen. Aus allen deklarierten Werten wählt die Kaskade einen Sieger (kaskadierter Wert). Fehlt einer, greift Vererbung oder der Anfangswert: Das ist der spezifizierte Wert. Der berechnete Wert löst relative Angaben auf, soweit das ohne Layout geht, etwa 1.5em bei 16 Pixel Elternschrift zu 24px. Der verwendete Wert entsteht erst im Layout, etwa wenn width: 50% zu konkreten Pixeln wird. Der tatsächliche Wert ist schließlich das, was das Gerät darstellen kann, zum Beispiel gerundete Pixel.
Praktisch wichtig ist das bei line-height: line-height: 1.5em wird schon beim Elternelement zu Pixeln berechnet, und genau dieser feste Wert wird vererbt. Eine größere Überschrift darin bekommt dann zu engen Zeilenabstand. line-height: 1.5 ohne Einheit vererbt dagegen den Faktor, der für jede Schriftgröße neu gilt.
Typische Fehler und wie die DevTools sie zeigen
Im Bereich Styles der Chrome-DevTools (Firefox und Edge arbeiten ähnlich) stehen alle Regeln, die ein Element treffen, sortiert nach ihrem Rang. Die Darstellung verrät die Ursache:
- Durchgestrichen: Die Deklaration wurde von einer anderen in der Kaskade überschrieben. Darüber steht die siegreiche Regel.
- Durchgestrichen mit Warnsymbol: ungültige Eigenschaft oder ungültiger Wert, oft ein Tippfehler wie
colouroder eine fehlende Einheit. - Blass mit Info-Symbol: gültig, aber wirkungslos, etwa
justify-contentan einem Element mitdisplay: block. - Abschnitte „Inherited from“: geerbte Werte samt Elternelement, von dem sie stammen.
- Kursiv: Stile des Browsers oder HTML-Attribute, nicht editierbar.
Fährt man mit der Maus über einen Selektor, zeigt Chrome dessen Spezifität an. Ebenen lassen sich über die Schaltfläche für die Cascade-Layers-Ansicht in ihrer Rangfolge anzeigen. Der Reiter Computed listet die berechneten Endwerte; mit „Show all“ auch vererbte Eigenschaften.
Die häufigsten Fehler aus der Praxis: Ein Framework-Stylesheet wird nach dem eigenen CSS geladen und gewinnt bei gleicher Spezifität durch die Reihenfolge. Eine ID im Selektor zwingt alle späteren Anpassungen zu noch stärkeren Selektoren. Und Formularelemente erben die Seitenschrift nicht, weil das Browser-Stylesheet ihnen eigene Schriftangaben gibt; font: inherit löst das. Bei Stapelproblemen mit überlagerten Elementen hilft die Kaskade übrigens nicht weiter, dort geht es um Stacking Contexts, erklärt im Beitrag zu position und z-index.
Quellen
- W3C: CSS Cascading and Inheritance Level 5
- W3C: CSS Cascading and Inheritance Level 6 (Working Draft, @scope)
- W3C: CSS2 (1998), Kapitel 6 Assigning property values, Cascading, and Inheritance
- MDN: Specificity
- MDN: @layer
- MDN: @scope
- Can I use: CSS Cascade Scope
- Chrome for Developers: CSS-Probleme im Styles-Bereich finden
