Seite 7 - Tailwind

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.

Tabellen auf Mobilgeräten horizontal zu scrollen ist keine Lösung – es ist Resignation. Mit Tailwind CSS responsive Tabellen richtig umzusetzen bedeutet: auf dem Smartphone ein Card-Layout, auf dem Desktop eine vollständige Tabelle, mit sticky Spalten, sortierbaren Kopfzeilen und kollabierbaren Zeilen für Detailansichten.

Tailwind CSS verleitet zu duplizierten Klassen-Strings in jedem Template. Eine sauber strukturierte Tailwind Komponenten-Bibliothek mit @layer components, CVA für Varianten und Design-Tokens als Single Source of Truth löst dieses Problem nachhaltig – ohne auf Utility-First-Vorteile zu verzichten.

CMS Blöcke in Magento werden von Redakteuren im WYSIWYG bearbeitet, nicht von Entwicklern in phtml Dateien. Ohne feste Hyvä CMS Block Styling Konventionen entstehen inkonsistente Layouts, kaputte Utility-Klassen, die vom Tailwind JIT Compiler nie generiert wurden, und CSP-Verletzungen durch Inline-Styles. Ein kleines, dokumentiertes Klassen-Set löst dieses Problem dauerhaft.

Wer Rechnungen aus einer PHP-Anwendung ohne Node.js-Abhängigkeit als PDF erzeugen will, landet fast immer bei Dompdf oder wkhtmltopdf. Beide Bibliotheken unterstützen nur einen Teil der CSS-Funktionen, die eine Tailwind-Vorlage im Browser nutzt, weshalb Rechnungslayouts bewusst auf Tabellen statt Flexbox aufgebaut werden müssen.

Wenn Tailwind CSS auf Bootstrap, Bulma oder gewachsenes Legacy-CSS trifft, überschreiben sich gleichnamige Klassen gegenseitig. Die Tailwind CSS Prefix-Option löst dieses Problem mit minimaler Konfiguration und maximaler Isolierung – dieser Artikel erklärt, wie und wann man sie einsetzt.

Tailwinds JIT-Engine generiert ausschließlich jene Utility-Klassen, die tatsächlich im Quellcode vorkommen, doch falsch konfigurierte Content-Pfade sorgen in der Praxis regelmäßig dafür, dass CSS-Bundles unnötig aufgebläht werden oder Styles im Produktivbetrieb plötzlich fehlen, weil der Scanner Templates, Module oder dynamisch zusammengesetzte Klassennamen schlicht übersieht.