Tailwind und das Ende meiner eigenen CSS-Dateien

Meine Reaktion, als ich Tailwind zum ersten Mal gesehen habe, war dieselbe wie bei den meisten: Das sieht furchtbar aus. Zwölf Klassennamen in einem Element, kein einziger davon sagt, was das Element ist. Das ist doch genau das, was man in jedem Anfängerkurs als schlechte Praxis lernt.

Ein halbes Jahr später hatte ich in meinem Dashboard genau eine CSS-Datei mit vier Zeilen, und ich wollte nicht mehr zurück.

Woran meine eigenen Stylesheets gescheitert sind

Bevor ich sage, was Tailwind gut macht, muss ich sagen, was vorher schlecht war — sonst klingt es nach Mode.

Ich wusste nie, ob ich etwas löschen darf. Meine Datei hatte nach einem Jahr Dashboard-Entwicklung gut tausend Zeilen. Darin Klassen wie .karte, .karte-klein, .karte-klein-aktiv, .karte--alt. Welche davon noch benutzt wurden, war nicht feststellbar, ohne das ganze Projekt zu durchsuchen. Also habe ich nichts gelöscht, und die Datei wuchs weiter.

Namen zu finden war anstrengender als das Stylen selbst. Für jeden Container einen sprechenden Namen zu erfinden, der nicht schon vergeben ist und in einem halben Jahr noch passt — das ist erstaunlich viel geistige Arbeit für ein div.

Änderungen hatten Fernwirkung. Ich ändere .karte, weil es auf der Serverseite besser aussehen soll, und mache damit die Anmeldeseite kaputt. Dieses Risiko war bei jeder Änderung im Kopf und hat dazu geführt, dass ich lieber eine neue Klasse angelegt habe, als eine bestehende anzupassen. Womit wir wieder bei Punkt eins wären.

Was Tailwind daran ändert

Der Kern ist simpel: Statt eine Klasse zu definieren, die mehrere Eigenschaften bündelt, setzt man die Eigenschaften direkt am Element — über kurze, vordefinierte Klassen.

<div class="rounded-2xl border border-neutral-800 bg-neutral-900 p-6 shadow-sm">
  <h2 class="text-lg font-semibold text-neutral-100">Servereinstellungen</h2>
  <p class="mt-2 text-sm text-neutral-400">Gilt nur für diesen Server.</p>
</div>

Die drei Probleme von oben verschwinden dabei nicht durch Magie, sondern weil sich die Frage nicht mehr stellt:

• Löschen ist gefahrlos, weil kein Stil außerhalb des Elements existiert. Element weg, Stil weg.
• Namen braucht man keine. Die einzige Benennung, die bleibt, ist die Komponente selbst — und die hat sowieso schon einen Namen.
• Fernwirkung gibt es nicht. Änderungen wirken genau dort, wo man sie hinschreibt.

Das ist der eigentliche Gewinn, und er ist kein ästhetischer. Ein Stylesheet ist ein globaler Zustand, und wie bei jedem globalen Zustand ist das Schwierige nicht das Anlegen, sondern das Ändern und Aufräumen.

Was mich zusätzlich überzeugt hat

Ein festes Maßsystem. p-4 ist immer derselbe Abstand. Vorher hatte ich padding: 16px, padding: 15px und padding: 1rem in derselben Anwendung, weil ich beim Schreiben nicht nachgesehen habe. Ein begrenzter Satz erlaubter Werte macht eine Oberfläche automatisch ruhiger.

Dunkelmodus ohne doppelte Pflege. Ein Präfix pro Klasse statt eines zweiten Stylesheets:

<div class="bg-white text-neutral-900 dark:bg-neutral-900 dark:text-neutral-100">

Responsive an Ort und Stelle. md:grid-cols-2 steht direkt neben grid-cols-1. Bei getrennten Stylesheets liegen diese beiden Angaben in verschiedenen Blöcken, manchmal hunderte Zeilen auseinander.

Wo Tailwind nicht hilft

Ich will das nicht als Werbung schreiben, deshalb die andere Seite.

Bei sich wiederholenden Bausteinen wird es unangenehm. Wenn dasselbe Knopf-Design an dreißig Stellen steht, hat man dreißigmal dieselbe Klassenkette. Die Lösung ist eine Komponente — nicht eine CSS-Klasse. Wer in einem Projekt arbeitet, das keine Komponenten kennt, hat mit Tailwind ein echtes Problem.

Die Lesbarkeit leidet, wenn man es übertreibt. Ein Element mit dreiundzwanzig Klassen ist unlesbar, egal welches System man benutzt. Bei mir ist das ein Zeichen dafür, dass ich zu viel in ein Element packe.

Es ersetzt kein Designsystem. Tailwind gibt einem Bausteine, keine Entscheidungen. Welche Abstufungen von Grau, welche Radien, welche Schriftgrößen zusammengehören — das muss man selbst festlegen. Wer das nicht tut, hat mit Tailwind genau dieselbe Uneinheitlichkeit wie vorher, nur schneller erzeugt.

Es macht Sonderfälle nicht schöner. Eine komplexe Animation, ein aufwendiges Rasterlayout, eine Druckansicht — dafür schreibt man weiterhin CSS, und das ist in Ordnung.

Was ich nach zwei Jahren anders mache

Ein paar Dinge haben sich im Umgang eingespielt, die ich beim Einstieg gerne gewusst hätte.

Die Konfiguration ist der eigentliche Ort für Designentscheidungen. Farben, Abstände, Radien, Schriftgrößen gehören dorthin und nicht als beliebige Werte in einzelne Elemente. Wer das nicht macht, hat dieselbe Uneinheitlichkeit wie mit handgeschriebenem CSS, nur schneller erzeugt.

Semantische Namen für Farben statt Zahlenskalen. Nicht „Grau 800", sondern „Oberfläche", „Linie", „Text gedämpft". Der Unterschied zeigt sich beim Dunkelmodus: Eine semantische Bezeichnung kann in beiden Modi einen anderen Wert haben, eine Zahlenskala nicht.

Wiederholung ist erst ab drei Vorkommen ein Problem. Zweimal dieselbe Klassenkette ist in Ordnung. Beim dritten Mal wird daraus eine Komponente — nicht früher, weil sonst Abstraktionen entstehen, die nach einer Woche nicht mehr passen.

Die Reihenfolge der Klassen sollte automatisch sortiert werden. Sonst diskutiert man mit sich selbst darüber, und bei Änderungen entstehen unnötige Unterschiede.

Wo ich weiterhin CSS schreibe

Damit der Eintrag nicht wie eine Werbung endet — es gibt Stellen, an denen ich nach wie vor normales CSS schreibe, und zwar ohne schlechtes Gewissen.

Die Grundgestaltung von Fließtext. Ein Blogbeitrag besteht aus Elementen, die aus Markdown entstehen. Dort kann man keine Klassen setzen. Also gibt es Regeln für Überschriften, Absätze, Listen und Codeblöcke innerhalb eines Textbereichs.

Aufwendige Animationen. Alles mit Zwischenschritten und eigener Zeitkurve.

Druckansichten. Selten gebraucht, und dann ist ein eigener Block einfacher als Klassen an jedem Element.

Das ist der Punkt, den ich beim Einstieg missverstanden hatte: Es ist kein Ersatz für CSS, sondern ein anderer Ort dafür. Und für die Fälle, in denen dieser Ort nicht passt, benutzt man weiterhin den alten.

Was ich dabei über Werkzeuge gelernt habe

Meine erste Ablehnung kam daher, dass ich das Werkzeug an einer Regel gemessen habe, die ich gelernt hatte („Trennung von Inhalt und Darstellung"), ohne zu prüfen, welches Problem diese Regel eigentlich lösen sollte.

Die Regel stammt aus einer Zeit, in der eine Webseite aus HTML-Dateien bestand, die von Hand gepflegt wurden. In dieser Welt ist ein zentrales Stylesheet ein enormer Fortschritt. In einer Welt aus Komponenten, in der Struktur und Darstellung ohnehin in derselben Datei stehen, löst dieselbe Regel ein Problem, das man nicht mehr hat.

Seitdem frage ich bei jedem „so macht man das nicht" zuerst: Wogegen war diese Regel gerichtet, und gilt das hier noch? Manchmal ja. Manchmal wiederholt man einen Grundsatz, dessen Grund verschwunden ist.