Seite 5 - Tailwind 4

Tailwind v4 nutzt native CSS Cascade Layers intern, um seine eigenen Stile in eine vorhersehbare Reihenfolge zu bringen. Wer versteht, wie dieses Zusammenspiel funktioniert, kann eigenes CSS und Drittanbieter-Stylesheets gezielt einordnen, statt Spezifitätskonflikte mit immer mehr !important zu bekämpfen.

Tailwind CSS v4 bringt einen neuen Compiler, CSS-first-Konfiguration, OKLCH-Farben und verbesserte Varianten. Dieses Cheatsheet deckt alle wichtigen Klassen und neuen Konzepte ab – als schnelle Referenz für den Entwickleralltag.

Wer keine Maus benutzt, verlässt sich vollständig auf eine funktionierende Tastaturnavigation. Skip-Links, eine logische Fokus-Reihenfolge und ein sauberer Focus-Trap in Modals entscheiden darüber, ob eine Tailwind CSS Anwendung für Tastaturnutzer bedienbar oder unbenutzbar ist.

Filter Utilities wie blur, brightness und grayscale wirken auf den ersten Blick wie kosmetische Spielerei, lösen in Tailwind aber ein technisch anspruchsvolles Problem: mehrere Filter-Funktionen werden zu einer einzigen CSS-Deklaration komponiert. Wer versteht, wie diese Komposition funktioniert und wo Backdrop-Filter an Grenzen stoßen, baut Effekte, die auch auf Mobilgeräten flüssig bleiben.

CMS-Content ohne Tailwind Typography Plugin zu stylen bedeutet: Hunderte von reset-Regeln manuell überschreiben. Das @tailwindcss/typography Plugin löst dieses Problem mit der prose-Klasse – und gibt Entwicklern gleichzeitig präzise Kontrolle über jeden typografischen Detail.

Ein separater Tailwind-Build für jeden White-Label-Kunden skaliert schlecht, sobald hundert Mandanten dieselbe Anwendung mit eigenem Farbschema nutzen wollen. Mit einem einzigen CSS-Bundle und serverseitig injizierten CSS-Variablen anhand des Hostnamens lässt sich White-Label-Theming ohne Rebuild pro Marke umsetzen, direkt auf Basis von Tailwind CSS v4 Design-Tokens.

Wer mit ml-4 und pl-6 arbeitet, schreibt physische CSS-Eigenschaften, die bei RTL-Sprachen wie Arabisch oder Hebräisch manuell gespiegelt werden müssen. Tailwind Logical Properties wie ms-4 und ps-6 lösen dieses Problem elegant: Sie passen sich automatisch an die Schreibrichtung des Dokuments an – kein separates RTL-Stylesheet, keine JavaScript-Logik.

Einfache group-hover- und peer-focus-Muster kennt jeder, der mit Tailwind arbeitet. Sobald aber mehrere Ebenen verschachtelt sind, mehrere Kindzustände nach oben durchgereicht werden müssen oder ein Formular auf den Zustand eines völlig anderen Elements reagieren soll, reichen die Basics nicht mehr aus. Named groups, group-has, peer-has und Datenattribut-Zustandsketten lösen genau diese fortgeschrittenen Group und Peer State Kombinationen.

Ein Themewechsel, der einfach nur die Klasse tauscht, wirkt technisch korrekt, fühlt sich aber ruckartig an. Mit der View Transitions API, mit @property registrierten Farbvariablen und einem schlanken Alpine.js Store lässt sich derselbe Wechsel in Tailwind CSS v4 als weiche Überblendung umsetzen, ganz ohne zusätzliche JavaScript-Bibliothek.

Utility-First oder scoped Stylesheets? Beide Ansätze haben klare Stärken und blinde Flecken. Wer Tailwind CSS und CSS Modules nur nach persönlichem Geschmack bewertet, verpasst die entscheidenden Architekturunterschiede – und wählt am Ende die falsche Lösung für sein Projekt.