ITCSS: Skalierbare CSS Architektur für große Projekte

1. Das Grundproblem: Spezifität ohne Ordnung

ITCSS steht für Inverted Triangle CSS und wurde von Harry Roberts als Antwort auf ein Problem entwickelt, das die meisten gewachsenen Stylesheets teilen, nämlich eine Spezifität, die mit der Projektlaufzeit chaotisch statt kontrolliert wächst. Ohne bewusste Architektur landen globale Grundregeln, komponentenspezifische Anpassungen und Ausnahmen für einzelne Sonderfälle in derselben Datei oder in willkürlich sortierten Dateien, deren Reihenfolge im Build-Prozess über Sieg oder Niederlage einer Regel entscheidet, nicht deren inhaltliche Bedeutung.

Die Kernidee von ITCSS ist denkbar einfach: Ein Stylesheet wird in Schichten organisiert, die von generisch und breit wirkend zu spezifisch und explizit verlaufen, dargestellt als umgekehrtes Dreieck. Ganz oben, an der breiten Seite des Dreiecks, stehen Regeln mit sehr geringer Spezifität und hoher Reichweite, etwa CSS Custom Properties und Reset-Regeln. Ganz unten, an der schmalen Spitze, stehen hochspezifische Ausnahmeregeln, die bewusst und selten eingesetzt werden. Diese CSS Architektur macht die Reihenfolge im Stylesheet zur direkten Abbildung der Spezifitätshierarchie, statt einer zufälligen Historie von Commits.

Der praktische Effekt: Ein Entwickler, der eine neue Regel hinzufügt, muss sich fragen, in welche Schicht sie gehört, nicht nur, welche Datei gerade offen ist. Diese Disziplin, konsequent über ein ganzes Projekt angewendet, verhindert den typischen Spezifitätskrieg, bei dem jede neue Regel eine noch spezifischere braucht, um sich durchzusetzen. ITCSS löst dieses Problem nicht durch Verbote, sondern durch eine klare Landkarte, wo jede Art von Regel hingehört.

2. Settings und Tools: die unsichtbaren Schichten

Die erste Schicht in ITCSS heißt Settings und enthält ausschließlich Variablen, keine tatsächlich gerenderten CSS-Regeln. Hierhin gehören Custom Properties für Farben, Spacing-Skalen, Breakpoints und Typografie-Werte. Diese Schicht erzeugt selbst keinen CSS-Output im Sinne sichtbarer Deklarationen, sondern definiert das Vokabular, das alle nachfolgenden Schichten verwenden. Der Vorteil: eine Änderung an einem Grundwert, etwa der primären Markenfarbe, propagiert automatisch durch das gesamte Stylesheet, ohne dass eine einzige Komponentenregel angefasst werden muss.

Die zweite Schicht, Tools, enthält Mixins und Funktionen, sofern ein Präprozessor wie Sass im Einsatz ist, oder wiederverwendbare Custom-Property-Berechnungen bei reinem CSS. Auch diese Schicht erzeugt keinen direkten Output, sie stellt Werkzeuge bereit, die spätere Schichten aufrufen. Eine häufige Faustregel in ITCSS: Wenn eine Schicht beim isolierten Kompilieren zu leerem CSS führt, gehört sie zu Settings oder Tools, nicht zu einer der folgenden, output-erzeugenden Schichten.

/* 1-settings/_colors.css — variables only, no rendered output */
:root {
  --color-brand-500: oklch(0.55 0.18 275);
  --color-brand-600: oklch(0.48 0.19 275);
  --color-surface: oklch(0.98 0.01 275);
  --space-unit: 0.25rem;
  --radius-md: 0.5rem;
}

/* 2-tools/_mixins.css — reusable helpers, still no direct output */
@custom-media --viewport-md (width >= 48rem);

/* Example Sass mixin equivalent, if a preprocessor is used:
@mixin focus-ring($color: var(--color-brand-500)) {
  outline: 2px solid $color;
  outline-offset: 2px;
}
*/

3. Generic und Elements: das globale Fundament

Die dritte Schicht, Generic, ist die erste, die tatsächlichen CSS-Output erzeugt. Hierhin gehören Reset- und Normalize-Regeln, Box-Sizing-Deklarationen und weitreichende Selektoren wie * oder ::before, ::after. Diese Regeln betreffen das gesamte Dokument gleichermaßen und haben bewusst minimale Spezifität, damit sie von jeder folgenden Schicht problemlos überschrieben werden können. In ITCSS ist es wichtig, dass diese Schicht keine Klassenselektoren enthält, ausschließlich Typ- und universelle Selektoren.

Die vierte Schicht, Elements, stylt nackte HTML-Elemente ohne jede Klasse: h1, a, table, input. Das ist die Ebene, auf der Standardtypografie und Standardverhalten für unstyled Content definiert werden, etwa in einem CMS-generierten Artikeltext, in dem keine Klassen zur Verfügung stehen. Diese CSS Architektur stellt sicher, dass selbst rohes, unklassifiziertes HTML sinnvoll aussieht, ohne dass es dafür einer einzigen Klasse bedarf.

/* 3-generic/_reset.css — broad reach, minimal specificity */
*, *::before, *::after {
  box-sizing: border-box;
  margin: 0;
}

/* 4-elements/_typography.css — bare HTML elements, no classes */
h1, h2, h3 {
  font-weight: 700;
  line-height: 1.2;
}

a {
  color: var(--color-brand-600);
  text-decoration-thickness: from-font;
}

table {
  border-collapse: collapse;
  width: 100%;
}

4. Objects: layoutbezogene, wiederverwendbare Muster

Die fünfte Schicht, Objects, orientiert sich am OOCSS-Prinzip von Nicole Sullivan: rein strukturelle, layoutbezogene Klassen ohne visuelle Gestaltung wie Farbe oder Typografie. Ein typisches Beispiel ist ein Grid-System oder ein Media-Object-Pattern, das Struktur definiert (etwa ein Bild links, Text rechts), aber keine Aussage über Farben oder Schriftgrößen trifft. Namenskonventionen wie ein vorangestelltes o- Präfix, etwa o-media, machen sofort erkennbar, dass diese Klasse zur Objects-Schicht gehört und rein strukturell gemeint ist.

Diese Schicht ist in ITCSS bewusst von Components getrennt, weil sie eine andere Wiederverwendbarkeit anstrebt. Ein Objects-Pattern soll in völlig unterschiedlichen visuellen Kontexten funktionieren, eine Karte, ein Kommentar, ein Produkt-Snippet können alle dieselbe o-media-Struktur nutzen, ohne dass diese Struktur irgendetwas über das Erscheinungsbild aussagt. Wer diese Trennung nicht einhält und Farben direkt in Objects-Klassen mischt, verliert genau den Wiederverwendbarkeitsvorteil, den diese Schicht bieten soll.

/* 5-objects/_media.css — structure only, no color, no typography */
.o-media {
  display: flex;
  align-items: flex-start;
  gap: var(--space-unit) * 4;
}

.o-media__figure {
  flex-shrink: 0;
}

.o-media__body {
  flex: 1 1 auto;
  min-width: 0; /* prevents flex overflow with long text */
}

/* Grid object, purely structural */
.o-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
  gap: calc(var(--space-unit) * 6);
}

5. Components: die eigentliche UI-Ebene

Die sechste Schicht, Components, ist dort, wo die meiste tägliche Entwicklungsarbeit stattfindet. Hier leben konkrete, benannte UI-Bausteine wie ein Button, eine Card oder ein Navigationsmenü, typischerweise mit dem Präfix c- gekennzeichnet, etwa c-button. Anders als Objects tragen Components volle visuelle Verantwortung, Farbe, Typografie, Schatten und Übergänge gehören hierhin. Diese Schicht kann intern Objects verwenden, etwa eine Card, die für ihr internes Layout das o-media-Muster nutzt, aber selbst die Farb- und Typografieentscheidungen trifft.

In der Praxis ist Components die Schicht, die am ehesten mit BEM oder einer ähnlichen Namenskonvention kombiniert wird, weil hier die meisten benannten, in sich geschlossenen UI-Einheiten entstehen. ITCSS macht keine Vorgabe, welche Namenskonvention innerhalb der Components-Schicht verwendet wird, es legt nur fest, wo diese Regeln im Spezifitätsgefälle stehen, nämlich deutlich spezifischer als Generic und Objects, aber unterhalb der letzten beiden Schichten.

/* 6-components/_button.css — full visual responsibility */
.c-button {
  display: inline-flex;
  align-items: center;
  gap: calc(var(--space-unit) * 2);
  padding-block: calc(var(--space-unit) * 3);
  padding-inline: calc(var(--space-unit) * 5);
  border-radius: var(--radius-md);
  background: var(--color-brand-500);
  color: white;
  font-weight: 600;
  transition: background-color 150ms ease;
}

.c-button:hover {
  background: var(--color-brand-600);
}

.c-button--secondary {
  background: transparent;
  border: 1px solid var(--color-brand-500);
  color: var(--color-brand-600);
}

6. Trumps: bewusste, dokumentierte Ausnahmen

Die siebte und letzte Schicht, Trumps, ist die spezifischste im gesamten ITCSS-System und enthält Utility-Klassen und, in seltenen, dokumentierten Fällen, !important-Deklarationen. Klassen wie u-hidden oder u-text-center gehören hierhin, weil sie bewusst jede vorherige Schicht überschreiben sollen. Der entscheidende Unterschied zu einem willkürlichen !important irgendwo im Code: In Trumps ist die hohe Spezifität beabsichtigt und an genau einer, klar definierten Stelle im Stylesheet konzentriert, statt über das gesamte Projekt verstreut.

Ein häufiger Fehler beim Einstieg in ITCSS ist, zu viele Regeln in Trumps zu packen, weil es der einfachste Weg ist, ein Spezifitätsproblem kurzfristig zu lösen. Diese CSS Architektur funktioniert aber nur, wenn Trumps klein und selten bleibt, im Idealfall nur einstellige Anzahl von Utility-Klassen für echte, seltene Layout-Ausnahmen. Wächst diese Schicht unkontrolliert, verliert das ganze System seinen Vorteil, weil wieder unklar wird, welche der vielen hochspezifischen Regeln in welchem Kontext gewinnt.

/* 7-trumps/_utilities.css — highest specificity, used sparingly and deliberately */
.u-hidden {
  display: none !important;
}

.u-visually-hidden {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
  clip: rect(0, 0, 0, 0) !important;
}

/* Deliberate, documented override for a rare edge case, not a habit */
.u-no-scroll {
  overflow: hidden !important;
}

7. ITCSS mit nativen Cascade Layers umsetzen

Seit der breiten Browserunterstützung für @layer lässt sich ITCSS nicht mehr nur über Dateireihenfolge, sondern nativ über CSS Cascade Layers durchsetzen. Das löst ein subtiles Problem der klassischen ITCSS-Umsetzung: Ohne Cascade Layers hängt die Spezifitätsreihenfolge zwischen den Schichten weiterhin von der Deklarationsreihenfolge im kompilierten Stylesheet ab. Eine versehentlich falsch importierte Datei kann die gesamte Architektur unterlaufen, ohne dass ein Fehler sichtbar wird, denn CSS wirft bei Spezifitätsproblemen keine Warnung.

Mit expliziten Layer-Deklarationen wird die Reihenfolge der Schichten unabhängig von der Dateireihenfolge garantiert. Ein Layer, der später deklariert wird, gewinnt gegenüber einem früher deklarierten Layer, unabhängig davon, wie spezifisch die einzelnen Selektoren innerhalb der Layer sind. Das macht ITCSS robuster gegenüber Build-Tool-Eigenheiten und Import-Reihenfolge-Fehlern, die in großen Projekten mit vielen Mitwirkenden erfahrungsgemäß irgendwann auftreten.

/* Layer order is declared once, independent of file import order */
@layer settings, tools, generic, elements, objects, components, trumps;

@import url("./1-settings/colors.css") layer(settings);
@import url("./3-generic/reset.css") layer(generic);
@import url("./4-elements/typography.css") layer(elements);
@import url("./5-objects/media.css") layer(objects);
@import url("./6-components/button.css") layer(components);
@import url("./7-trumps/utilities.css") layer(trumps);

/* Even if imported out of order below, "trumps" always wins over "components" */

8. ITCSS in ein bestehendes Projekt einführen

Ein vollständiger Rewrite auf ITCSS ist bei gewachsenen Projekten selten realistisch und meist auch nicht nötig. Der pragmatischste Einstieg ist, neue Regeln von Anfang an nach dem ITCSS-Schema zu organisieren, während bestehende Regeln schrittweise in die passende Schicht migriert werden, sobald sie ohnehin angefasst werden müssen. Ein separater Ordner für neue ITCSS-Dateien, importiert nach dem bestehenden Legacy-Stylesheet, erlaubt eine Koexistenz beider Systeme während der Übergangsphase.

Ein häufiger erster Schritt ist, die Settings-Schicht zu etablieren, also alle verstreuten Hex-Farbwerte und Magic Numbers im bestehenden CSS durch Custom Properties zu ersetzen, ohne die Struktur der übrigen Regeln sofort zu verändern. Dieser Schritt allein liefert bereits messbaren Nutzen, weil zukünftige Farb- oder Spacing-Änderungen zentral erfolgen können, noch bevor die vollständige ITCSS-Migration abgeschlossen ist.

9. ITCSS im Vergleich zu anderen Ordnungsprinzipien

ITCSS konkurriert nicht direkt mit BEM oder Utility First, es ist eher eine Meta-Ebene, die festlegt, wo Regeln in welcher Schicht platziert werden, unabhängig von der verwendeten Namenskonvention innerhalb dieser Schichten. Die folgende Tabelle vergleicht ITCSS dennoch mit den gängigsten Alternativen zur Stylesheet-Organisation, um die jeweiligen Stärken einzuordnen.

In der Praxis schließen sich diese Ansätze nicht aus. Ein Team kann Atomic Design für die Komponentenhierarchie nutzen und gleichzeitig ITCSS für die Reihenfolge der zugrunde liegenden CSS-Regeln, weil beide unterschiedliche Fragen beantworten, nämlich wie Komponenten strukturiert sind versus in welcher Spezifitätsreihenfolge ihre Regeln geladen werden.

10. Zusammenfassung

ITCSS löst das Grundproblem gewachsener Stylesheets, indem es Regeln nach Spezifität und Reichweite statt nach Dateityp oder Zufall ordnet. Die sieben Schichten, Settings, Tools, Generic, Elements, Objects, Components und Trumps, bilden gemeinsam ein umgekehrtes Dreieck, das von breiten, generischen Regeln zu engen, hochspezifischen Ausnahmen verläuft. Diese CSS Architektur macht vorhersagbar, welche Regel gewinnt, ohne dass ein Entwickler die gesamte Import-Historie eines Projekts kennen muss.

Native Cascade Layers verstärken diesen Vorteil zusätzlich, weil sie die Schichtreihenfolge unabhängig von der tatsächlichen Dateireihenfolge im Build garantieren. Für Teams, die ITCSS neu einführen wollen, ist eine schrittweise Migration realistischer als ein vollständiger Rewrite, beginnend mit der Settings-Schicht und einer klaren Konvention für neue Regeln, während bestehender Code bei Gelegenheit nachgezogen wird.

11. FAQ: ITCSS und skalierbare CSS Architektur