CSS Keywords zum Reseten: Warum „einfach zurücksetzen“ oft nicht einfach ist

erstellt am: 24.01.2026 | Kategorien: Webentwicklung | Schlagworte: css

CSS wirkt manchmal herrlich direkt: Du setzt einen Wert – du bekommst ein Ergebnis. Und wenn du „zurück“ willst, nimmst du eben einen der bekannten Keywords: initial, inherit, unset, revert, revert-layer. Klingt nach einem sauberen Werkzeugkasten.

In der Praxis ist genau das der Punkt: Diese Keywords sind nicht nur „Werte“, sondern greifen in die Kaskade, in Vererbung und in Browser-Defaults ein. Und sobald man von „Was sehe ich?“ zu „Warum passiert das?“ geht, merkt man: Ohne ein klares mentales Modell verheddert man sich schnell.

Für alle Keyords habe ich eine Demo Seite gebaut

„Reset“ in CSS bedeutet nicht automatisch „Standardwert“.
Es bedeutet meistens: „Zurück zu einem bestimmten Mechanismus der Kaskade.“

Und genau deshalb ist ausgerechnet revert ein gutes Beispiel dafür, wie schnell Intuition und Realität auseinanderlaufen.

revert: Der Keyword, der dich zuerst anlügt (gefühlt)

Wenn du revert zum ersten Mal benutzt, erwartest du oft etwas wie:

• „Nimm den normalen Wert“
• „Geh zurück auf den Default“
• „So als hätte ich es nie gesetzt“

Das klingt plausibel – und ist trotzdem nur teilweise richtig.

Denn revert ist kein „Reset auf Initialwert“ (das wäre eher initial), und es ist auch kein „wie unset“ (das unterscheidet explizit nach vererbbar / nicht vererbbar). revert macht etwas anderes:

Es rollt die Kaskade auf die vorherige Ursprungsebene zurück
(typisch: von Author CSS zurück zu User/UA).

Das ist ein konzeptioneller Unterschied. Und der sorgt dafür, dass revert je nach Property und Element komplett unterschiedliche Effekte haben kann – sogar bei vererbbaren Eigenschaften.

Ein Beispiel: revert sieht manchmal aus wie inherit und manchmal gar nicht

Hier ist die Denkfalle: Viele sagen sinngemäß „bei vererbbaren Eigenschaften wirkt revert wie inherit“. Das kann stimmen aber nur, wenn nach dem Zurückrollen kein anderer Wert übrig bleibt und dann die Vererbung „einspringt“.

Das siehst du gut an diesem Beispiel (zwei Demos, jeweils vererbbare Eigenschaft):

1) font-size auf h1: revert ist nicht inherit

Du setzt beim Parent font-size: 14px. Dann:

• inherit am h1 ergibt exakt 14px.
• revert am h1 führt häufig dazu, dass der Browser wieder seine UA-Regel für h1 nutzt – oft 2em.

Und jetzt kommt der wichtige Teil:
Wenn der UA-Wert 2em ist, dann ist das relativ zum Parent, den du auf 14px gesetzt hast. Also wird 2em zu etwa 28px.

Ergebnis: revert macht den h1 wieder „typisch h1-groß“ und eben nicht „wie der Parent“.

2) color auf span: revert wirkt wie inherit

Beim Parent color: green. Dann:

• inherit am span ergibt grün.
• revert am span wird meistens ebenfalls grün.

Warum? Weil der Browser für ein normales span in der Regel keine spezielle UA-Farbe setzt. Wenn revert die Author-Regel entfernt, bleibt kein UA/User-Wert übrig und dann greift das Defaulting: vererbbare Eigenschaften werden vererbt.

Ergebnis: revert sieht aus wie inherit, aber nicht weil es „inherit macht“, sondern weil nach dem Rollback Vererbung das Fallback ist.

Was du daraus mitnehmen solltest

1) revert ist kein „Reset auf Standardwert“

Es ist ein Origin-Rollback. Das kann UA-Regeln sichtbar machen, die du gar nicht auf dem Schirm hattest.

2) „Wirkt wie inherit“ ist kein Gesetz, sondern ein häufiges Ergebnis

Bei vererbbaren Properties kann revert wie inherit aussehen wenn UA/User nichts Spezifisches liefert. Bei Elementen mit UA-Spezialregeln (z. B. h1) kann es deutlich anders ausfallen.

3) Für sauberes Debugging brauchst du „Computed“

Wenn du revert verwendest, schau nicht nur „wie es aussieht“, sondern prüfe den berechneten Wert (DevTools → Computed). Das ist der schnellste Weg, um Kaskade vs. Vererbung auseinanderzuhalten.

Link zur Demo

Ich verlinke die konkreten Demo als Codepen, damit man sie isoliert testen und erweitern kann.

👉 Codepen Demo

Als erster einen Kommentar schreiben.