Was ist Tailwind CSS?

Tailwind CSS ist ein Utility First CSS Framework. Ihr stylt direkt im Markup mit kleinen Klassen wie flex, p-4 oder text-lg, und Tailwind erzeugt beim Build nur das CSS, das ihr wirklich nutzt.

Seit Version 4 läuft die Konfiguration komplett in CSS. Design Tokens wie Farben, Abstände und Schriften stehen in einem @theme Block, eine tailwind.config.js braucht ihr nicht mehr.

Wir nutzen Tailwind täglich in Production. Das Styling unserer Astro Projekte läuft durchgehend darüber, genauso in React und Vue Komponenten. Auf dieser Seite zeigen wir, was Tailwind CSS 2026 kann, was in v4.2 und v4.3 neu ist und wie ihr es sauber mit Barrierefreiheit und KI Coding verbindet.

Tailwind ist bei uns kein Experiment. Wir bauen damit jeden Tag Frontends mit Astro, React und Vue und sichern sie mit TypeScript, Cypress und Pipelines in GitHub Actions und GitLab CI ab. Dazu kommt ein starker Fokus auf Barrierefreiheit: Fokuszustände, Kontraste und Tastaturbedienung prüfen wir im Code und im Test. So wissen wir, wo Tailwind glänzt und wo ein Projekt ohne klare Regeln schnell unübersichtlich wird.

Wir helfen Teams beim Umstieg auf Astro mit Tailwind, beim Neuaufbau von Lovable und Base44 Projekten mit Astro und bei barrierefreiem Webdesign. Für KI generierten Frontend Code setzen wir AI Coding Guidelines für TypeScript und NCA Agentic AI Coding Guardrails auf, und mit einem Codebase Audit für KI generierten Code sehen wir schnell, wo euer Styling aus dem Ruder läuft.

Klassisches CSS startet mit einem Klassennamen wie .card und einer eigenen Datei voller Regeln. Tailwind dreht das um. Jede Klasse macht genau eine Sache, und ihr setzt das Design im Markup aus diesen Bausteinen zusammen.

Was ihr davon habt:

• Kein Namensstreit: Ihr müsst keine Klassennamen erfinden und keine BEM Konventionen pflegen.
• Kleines CSS: Der Build scannt eure Dateien und liefert nur die Klassen aus, die vorkommen.
• Zustände direkt im Markup: Varianten wie hover:, focus-visible:, md: oder dark: hängen vor der Klasse.
• Konsistenz: Alle Werte kommen aus einem gemeinsamen Theme. Wer p-4 schreibt, bekommt überall denselben Abstand.

Der Preis: Lange Klassenlisten im Markup. Das ist gewollt, braucht aber Ordnung. Wiederkehrende Muster gehören in Komponenten, etwa eine Astro, React oder Vue Komponente für Buttons. So steht die Klassenliste an genau einer Stelle.

Mit Version 4 hat Tailwind seine Basis neu gebaut. Die Engine heißt Oxide und bringt vor allem bei inkrementellen Builds einen deutlichen Sprung. Die größte Änderung im Alltag ist aber die Konfiguration: Sie wandert aus JavaScript in eure CSS Datei.

Jede Variable im @theme Block wird zu Klassen. Aus --color-brand entstehen bg-brand, text-brand und border-brand. Gleichzeitig stehen alle Werte als echte CSS Variablen bereit, die ihr überall nutzen könnt.

Weitere Punkte, die v4 für uns besser machen:

• Automatische Content Erkennung: Tailwind findet eure Template Dateien selbst, das content Array fällt weg.
• Modernes CSS als Basis: Cascade Layers, @property und color-mix() stecken unter der Haube.
• Farben in OKLCH: Die Standardpalette nutzt den OKLCH Farbraum, das macht Helligkeit und Kontrast besser planbar.
• Container Queries eingebaut: Mit @container und Varianten wie @md: reagieren Komponenten auf ihren eigenen Platz.
• Upgrade Tool: npx @tailwindcss/upgrade migriert v3 Projekte zum großen Teil automatisch.

Wichtig für ältere Projekte: v4 setzt moderne Browser voraus. Wer sehr alte Browser unterstützen muss, bleibt vorerst bei v3.4 oder plant den Wechsel bewusst. Wie ihr Markenfarben sauber als Tokens anlegt, zeigen wir im Blog Artikel Brand Colors in Tailwind CSS v4.

Die aktuelle Linie ist Tailwind CSS v4.3. Das Team hat v4.2 und v4.3 in einem gemeinsamen Release Artikel vorgestellt. Das sind die Neuerungen, die im Projektalltag zählen.

Neu in v4.2:

• Vier neue Paletten: mauve, olive, mist und taupe ergänzen die Grautöne um wärmere und kühlere Varianten.
• Eigenes webpack Plugin: @tailwindcss/webpack spart den Umweg über PostCSS. Laut Tailwind Team ist der Build in großen Projekten damit mehr als doppelt so schnell.
• Mehr Logical Properties: Klassen wie pbs-*, mbs-*, inline-*, block-* sowie inset-s-* und inset-e-*. Die alten start-* und end-* Klassen gelten als veraltet.
• font-features: Mit font-features-* steuert ihr OpenType Features ohne eigenes CSS.

Neu in v4.3:

• Scrollbars stylen: scrollbar-thin, scrollbar-none, scrollbar-thumb-* und scrollbar-track-*. Dazu scrollbar-gutter-stable gegen Layout Sprünge.
• @container-size: Container Queries können jetzt auch auf die Höhe reagieren.
• zoom und tab: Neue Klassen für die CSS Eigenschaften zoom und tab-size, praktisch für Code Beispiele.
• Besseres @variant: Gestapelte und kombinierte Varianten direkt im CSS.
• Standardwerte für eigene Utilities: Mit --default() funktioniert eine eigene Utility mit und ohne Wert.

Das Update ist in bestehenden v4 Projekten unkompliziert. Ihr zieht tailwindcss und euer Build Plugin auf die neueste Version und lasst eure Tests laufen. In unseren Projekten erledigt Renovate solche Updates als Pull Request, die Pipeline mit Cypress entscheidet dann über den Merge.

Astro und Tailwind passen perfekt zusammen. Astro liefert standardmäßig HTML ohne JavaScript aus, Tailwind liefert nur das CSS, das auf den Seiten vorkommt. Das Ergebnis sind sehr schlanke Seiten mit guten Core Web Vitals. In Astro richtet ein einziger Befehl Tailwind v4 über das offizielle Vite Plugin ein.

Danach steht Tailwind in einer globalen CSS Datei. Dort legen wir auch die Design Tokens des Projekts ab.

So bauen wir Astro Projekte mit Tailwind auf:

• Komponenten statt Kopien: Buttons, Karten und Formularfelder sind Astro Komponenten. Interaktive Teile laufen als Astro Islands mit React oder Vue und nutzen dieselben Klassen.
• Tokens an einer Stelle: Farben, Radien und Schriften stehen nur im @theme Block. Beliebige Werte wie w-[347px] sind die Ausnahme.
• Typsicherheit dazu: Varianten von Komponenten typisieren wir mit TypeScript im strict Mode, so passt der Prop immer zur Klasse.
• Messen statt raten: Ladezeiten prüfen wir mit Felddaten aus dem CrUX Report.

Tailwind bringt keine fertigen Komponenten mit. Für Barrierefreiheit ist das ein Vorteil: Ihr müsst nichts entschärfen, was eine UI Library falsch vorgibt. Die Verantwortung liegt aber komplett bei euch. Diese Werkzeuge nutzen wir dafür:

• Fokus sichtbar machen: focus-visible:outline-2 und focus-visible:outline-offset-2 zeigen den Fokus bei Tastaturbedienung klar an. outline-none ohne Ersatz ist tabu.
• Nur für Screenreader: sr-only versteckt Text optisch und lässt ihn für Screenreader lesbar.
• Weniger Bewegung: motion-reduce: schaltet Animationen ab, wenn Nutzer das im System eingestellt haben.
• Hoher Kontrast: forced-colors: passt Elemente an den Kontrastmodus von Windows an.
• ARIA Zustände: Varianten wie aria-expanded: koppeln das Styling an den echten Zustand statt an eigene Klassen.

Der größte Stolperstein sind Kontraste. Die Standardfarben sind nicht automatisch WCAG konform. Grauer Text auf hellem Grund fällt schnell unter 4,5 zu 1. Deshalb legen wir geprüfte Farbpaare als Tokens an und nutzen nur diese für Text. Lesbarkeit hängt auch an Zeilenhöhen, dazu mehr bei line-height nach WCAG.

Automatisch prüfen wir mit axe und Cypress in der Pipeline. Wer ein altes Frontend mit viel jQuery hat, findet bei JavaScript ablösen für Barrierefreiheit und Performance den Weg zu sauberem Markup, auf dem Tailwind richtig wirkt.

Fragt ihr ein Sprachmodell nach einer Oberfläche, bekommt ihr fast immer Tailwind. Die Modelle haben unzählige Beispiele gesehen und schreiben die Klassen flüssig. Das Problem kommt später: Jeder Prompt erfindet neue Abstände, neue Grautöne und neue Button Varianten. Nach ein paar Wochen hat das Projekt zehn Blautöne und keiner weiß mehr, welcher gilt.

Deshalb bekommt der Agent bei uns feste Regeln. In OpenCode stehen sie in den Projektregeln, die bei jeder Aufgabe mitgeladen werden:

• Nur Tokens: Farben, Radien und Schriften kommen aus dem @theme Block. Beliebige Werte in eckigen Klammern sind verboten, außer mit Begründung.
• Erst Komponente, dann Klasse: Gibt es schon einen Button, wird er genutzt. Neue Varianten entstehen in der Komponente.
• Feste Reihenfolge: Klassen werden sortiert, damit Diffs lesbar bleiben.
• Barrierefreiheit ist Pflicht: Jedes interaktive Element braucht einen sichtbaren Fokus und geprüfte Kontraste.

Regeln allein reichen nicht. Entscheidend sind Quality Gates, die der Agent nicht umgehen kann: TypeScript Checks, Cypress Tests und Accessibility Prüfungen in der Pipeline. Wie das für Frontend Projekte aussieht, beschreiben wir in den AI Coding Guidelines für TypeScript. Wer einen Prototyp aus Lovable mitbringt, hat meist schon Tailwind im Code. Das hilft beim Neuaufbau, weil das Verhalten der Oberfläche als Referenz dient.

Tailwind Labs, die Firma hinter Tailwind CSS, gehört jetzt zu Shopify. Gründer Adam Wathan hat das im offiziellen Blog angekündigt. Shopify war eines der ersten großen Unternehmen, das Tailwind im großen Stil eingesetzt hat.

Für eure Projekte ist die Lage klar:

• Lizenz bleibt: Tailwind CSS und die anderen Open Source Projekte bleiben unter MIT Lizenz.
• Team bleibt: Das bisherige Team führt und pflegt die Projekte weiter, jetzt mit Rückendeckung von Shopify.
• Kommerzielle Produkte: Für Tailwind Plus und ui.sh nimmt Tailwind Labs keine neuen Kunden mehr an. Bestehende Kunden behalten den Zugang.

Hintergrund ist ein schwieriges Jahr. Tailwind wird mehr genutzt als je zuvor, aber KI Coding Tools haben das Geschäft mit Templates stark getroffen, weil Entwickler seltener in die Doku und auf die Produktseiten kommen. Für uns ist der Schritt ein gutes Signal: Das Framework hat jetzt ein stabiles Zuhause, und der Code bleibt frei nutzbar.

Tailwind steckt bei uns in fast jedem Frontend. Ein paar typische Einsätze:

• Neue Websites mit Astro: Statische Seiten mit Tailwind als einzigem Styling, dazu Islands für interaktive Teile. Mehr dazu bei Astro als Static Site Generator.
• KI Prototypen in Production bringen: Aus Lovable und Base44 Projekten erstellen wir eine OpenSpec und bauen mit Astro und Tailwind neu. Der Weg steht bei Vibe Coding Hilfe vom Prototyp zur Produktion.
• Barrierefreie Frontends: Eigene Utilities für Fokus und Kontrast, die Designer und Entwickler gemeinsam nutzen. Hintergrund bei barrierefreies Webdesign.
• Formulare mit Validierung: Tailwind für den Zustand im Markup, Zod 4 für die Daten dahinter.

Bei bestehenden Projekten starten wir mit einem Blick in den Code. Wie viele Tokens gibt es, wie viele beliebige Werte, wo fehlt ein Fokus? Daraus entsteht ein Plan, der Schritt für Schritt aufräumt, abgesichert durch Tests. Alle Frontend Themen findet ihr gesammelt unter Frontend Development.

Die wichtigsten Antworten zu Tailwind CSS, v4, Astro, Barrierefreiheit und KI Coding.