Tailwind

Wer Produktbilder und CMS-Assets weiterhin nur als JPEG oder PNG ausliefert, verschenkt bei jedem Seitenaufruf Ladezeit und Core-Web-Vitals-Punkte. Eine automatisierte WebP-Konvertierung im Build- und Deploy-Prozess erzeugt zu jedem Bild eine deutlich kleinere WebP-Variante, liefert sie über das picture-Element mit sauberem Fallback aus und lässt sich vollständig in die bestehende Hyvä-Deploy-Sequenz integrieren, ohne den Storefront bei einem Konvertierungsfehler zu gefährden.

Kaum ein Migrationsprojekt schaltet an einem Stichtag komplett von styled-components oder Emotion auf Tailwind um, meist existieren beide Ansätze über Wochen oder Monate parallel im selben Codebase. In dieser Uebergangsphase treffen zwei grundverschiedene Styling-Philosophien aufeinander: Tailwinds statische Utility-Klassen einerseits und zur Laufzeit generierte, gehashte Klassennamen von CSS-in-JS-Bibliotheken andererseits. Wer die Spezifitäts- und Injection-Order-Mechanik beider Systeme versteht, kann diese Koexistenz kontrolliert gestalten statt sie dem Zufall zu überlassen.

Eine Bildergalerie muss auf jedem Bildschirm ein sauberes Vorschau-Raster zeigen und beim Öffnen eines Bildes nahtlos in eine Vollbild-Lightbox übergehen, ohne dass Nutzerinnen mit Tastatur oder auf langsamer Verbindung benachteiligt werden. Dieses Muster zeigt den kompletten Aufbau mit Tailwind CSS und Alpine.js: vom responsiven Grid über die Zoom-Transition beim Öffnen bis zu Pfeiltasten-Navigation und Lazy-Loading für viele Bilder.

@apply ist eines der kontroversesten Features in Tailwind CSS. Zu Unrecht pauschal verurteilt, zu schnell unbedacht eingesetzt. Dieser Artikel zeigt genau, wann @apply echten Mehrwert liefert, wann es den Utility-First-Ansatz unterläuft und welche sauberen Alternativen den Architektur-Kompromiss vermeiden.

Wer Farben, Abstände und Typografie manuell zwischen Figma und Tailwind CSS synchronisiert, schafft Inkonsistenzen und Mehrarbeit. Design Tokens als Single Source of Truth verbinden Figma Variables direkt mit Tailwind CSS v4 – automatisch, skalierbar und Multi-Theme-fähig.

Cards sind das universellste UI-Pattern im Web. Gleichzeitig entstehen in Tailwind-Projekten ohne Card-System schnell Dutzende verschiedener Card-Implementierungen – jede etwas anders, keine wirklich wiederverwendbar. Dieser Artikel zeigt, wie man mit Tailwind CSS ein vollständiges Card-System mit allen wichtigen Varianten aufbaut.

Weihnachtsfarben, die im Januar noch im Code herumliegen, oder ein Black-Friday-Banner, das jemand manuell wieder entfernen muss: Copy-Paste-Anpassungen für saisonale Kampagnen hinterlassen dauerhaften Aufräumbedarf. Eine eigene CSS-Schicht mit zeitgesteuerter Aktivierung löst das Problem strukturell und baut sich nach Kampagnenende von selbst zurück.

Utility-Klassen aus Tailwind CSS werden von den meisten E-Mail-Clients ignoriert, weil externe Stylesheets im Postfach nicht ankommen. Eine Build-Pipeline, die Tailwind kompiliert und die erzeugten Regeln automatisch als Inline Styles in jedes HTML-Element schreibt, löst dieses Problem ohne manuellen Zusatzaufwand.

Eine Datentabelle mit hunderten Zeilen entscheidet über die Produktivität eines ganzen Teams. Wer Tailwind CSS Datentabellen ohne Zebra Muster, Sticky Header und klare Sortierindikatoren baut, zwingt Nutzer dazu, Zeile für Zeile mit dem Finger auf dem Bildschirm mitzuzählen. Dieser Artikel zeigt konkrete Styling Muster für Datentabellen, die auch bei großen Datenmengen scanbar bleiben.

Tailwind CSS v4 ist keine inkrementelle Verbesserung, sondern eine komplette Neuarchitektur. Die Oxide-Engine ersetzt den Node.js-basierten Build-Prozess durch eine Rust-native Implementierung, @theme ersetzt tailwind.config.js und der CSS-First-Ansatz verändert grundlegend, wie Tailwind konfiguriert wird.