Tailwind CSS ohne Chaos: fünf Regeln, die im Team halten 2026

Tailwind ist schnell. Klassen ins Markup, Ansicht neu laden, sieht gut aus. Genau das ist die Falle. Nach ein paar Monaten steht in jeder zweiten Zeile eine Klassenliste mit fünfzehn Einträgen, niemand weiß mehr, welcher Blauton der richtige ist, und ein Pull Request Diff liest sich wie ein Kassenbon.

Das Problem ist nicht das Framework. Es ist der fehlende Rahmen drumherum. Hier sind die Regeln, die den Unterschied machen, und die Voraussetzungen, ohne die ihr Tailwind besser gar nicht erst anfasst.

Zwei Voraussetzungen, sonst wird es zäh

Erstens: Ihr braucht feste Design Werte. Farben, Abstände, Schriftgrößen einmal definiert und überall wiederverwendet. Ohne das landen überall eckige Klammern im Markup, p-[13px] hier, mb-[11px] da, und die Farbe des Buttons steht als Hexwert an sechzig Stellen. Eine Designänderung wird dann zur Suchen und Ersetzen Aktion mit Restrisiko.

In Tailwind 4 gehört das direkt in die CSS Datei:

@theme {
  --color-primary: oklch(72% 0.21 152);
  --color-surface: oklch(20% 0.02 265);

  --spacing-sm: 4px;
  --spacing-md: 8px;
  --spacing-lg: 16px;
}

Danach heißt es im Markup bg-primary statt einem Hexwert, und eine Farbanpassung passiert an genau einer Stelle.

Zweitens: Ihr braucht Komponenten. Der Nutzen der Werte verpufft, wenn dieselbe Klassenliste an vierzig Stellen kopiert steht. Alles, was zweimal vorkommt, wird eine Komponente. Wer in einer Umgebung arbeitet, in der das nicht geht, fährt mit klassischen CSS Modulen besser.

Und ein Anti Muster gleich dazu: @apply als Abkürzung, um Klassenlisten in eigene CSS Klassen zu schieben. Das sieht aufgeräumt aus, hebt aber die Isolierung wieder auf, die Tailwind gerade bringt, und bläst das CSS auf. In Tailwind 4 braucht es dafür in separat gebündelten Styles zusätzlich einen @reference Import — ein guter Zeitpunkt, es einfach zu lassen.

Regel 1: So wenig Klassen wie möglich

Jede zusätzliche Klasse ist Text, den später jemand lesen muss. Vieles lässt sich kürzen, ohne dass sich am Ergebnis etwas ändert:

• pt-4 pb-4 wird py-4, gilt genauso für px, mx und my
• flex flex-row justify-between wird flex justify-between, weil die Zeilenrichtung der Standardwert ist
• border border-2 border-black border-opacity-50 wird border-2 border-black/50

Wer die Standardwerte der CSS Eigenschaften kennt, streicht solche Klassen im Vorbeigehen. Das ist keine Kosmetik, sondern spart bei jedem späteren Blick ins Markup Sekunden.

Regel 2: Werte gruppieren und ehrlich benennen

Werte einfach untereinander zu kippen führt zur nächsten Unordnung. Farben zu Farben, Abstände zu Abständen, Breakpoints zu Breakpoints. Und die Namen beschreiben den Zweck, nicht das Aussehen. Aus dem Designtool kommt vielleicht ein bright-red, im Projekt heißt es error. Ändert sich später der Rotton, passt der Name immer noch.

Dieselbe Disziplin gilt für Abstände: sm, md, lg statt 15px, 16px, 17px. Wenn drei Abstände existieren, die sich um zwei Pixel unterscheiden, ist das kein Designsystem mehr, sondern eine Sammlung.

Regel 3: Reihenfolge automatisieren

Klassenlisten sind schneller zu erfassen, wenn sie immer derselben Ordnung folgen: erst Layout, dann Größen, dann Farben, dann Typografie. Das von Hand durchzuhalten schafft kein Team.

Also übernimmt das ein Werkzeug. Das offizielle Prettier Plugin sortiert die Klassen beim Speichern, und in der Pipeline prüft ein Lauf, dass nichts unsortiert durchrutscht. Das ist derselbe Gedanke wie bei statischer Analyse im Backend: eine Diskussion weniger im Review. Wie so eine Kette aussieht, steht bei den CI CD Pipelines.

Regel 4: Varianten statt beliebiger Klassen von außen

Der Klassiker in React und Vue Projekten: Eine Komponente nimmt eine className Prop entgegen, und jeder Aufruf schiebt eigene Utilities hinein. Nach kurzer Zeit gibt es sieben Buttons, die alle ein bisschen anders aussehen, und niemand hat das entschieden.

Besser sind feste Varianten, die die Komponente kennt:

const BUTTON_VARIANTS = {
  primary: 'bg-primary text-surface hover:opacity-90',
  secondary: 'bg-surface text-primary border border-primary',
  danger: 'bg-error text-white hover:opacity-90',
};

Aufgerufen wird dann mit variant="secondary". Ihr verliert etwas Freiheit und gewinnt dafür ein Element, das überall gleich aussieht und sich an einer Stelle ändern lässt. Genau dafür baut man ein Designsystem.

Regel 5: Das gebaute CSS klein halten

Bei Tailwind 4 ist die Minimierung eingebaut, dort müsst ihr nichts einrichten. Wer noch auf Version 3 sitzt, kümmert sich selbst darum, über die CLI mit der Minify Option oder über einen entsprechenden PostCSS Schritt. Ein unminimiertes Stylesheet ist auf einer Landing Page der unnötigste Ladezeitverlust überhaupt.

Der Teil, der 2026 dazukommt: Agents

Ein KI Agent kennt eure Werte nicht, wenn ihr sie ihm nicht sagt. Er kennt Millionen Beispiele aus dem offenen Netz, und dort steht überall bg-[#00ff7f] und p-[13px]. Genau das schreibt er dann auch, sehr schnell und sehr viel.

Drei Dinge helfen dagegen:

• Werte in die Projektregeln. Die verfügbaren Farben, Abstände und Varianten gehören in die Regeldatei des Agents, zusammen mit dem Satz, dass eckige Klammern im Markup nicht erlaubt sind.
• Ein Gate, das es prüft. Eine Lint Regel gegen beliebige Werte fängt den Rückfall zuverlässiger ab als jeder gute Vorsatz im Review.
• Barrierefreiheit gesondert prüfen. Agents setzen gern Farbkombinationen mit zu wenig Kontrast und entfernen Fokusrahmen, weil es aufgeräumter aussieht. Beides fällt in einem Screenshot nicht auf und im Betrieb sofort. Der Einstieg dazu steht beim barrierefreien Webdesign.

Kurzcheck

• Gibt es feste Werte für Farben, Abstände und Schrift, an einer Stelle definiert?
• Ist alles, was mehrfach vorkommt, eine Komponente?
• Sortiert ein Werkzeug die Klassen, und prüft die Pipeline das nach?
• Haben Komponenten feste Varianten statt beliebiger Klassen von außen?
• Stehen die Werte auch in den Regeln für den KI Agent?

Fünf Fragen, und ihr wisst, ob euer Projekt in einem halben Jahr noch Spaß macht. Wie so ein Setup insgesamt aussieht, steht im Überblick zu Vibe Coding und bei den Vibe Coding Best Practices.