Zum Inhalt springen
CASOON

Tailwind CSS v4.2: Neuerungen im Praxischeck

Entwicklung

Webpack-Plugin, neue Farbpaletten, Logical Properties – was davon wirklich relevant ist und für wen

12 Minuten
Tailwind CSS v4.2: Neuerungen im Praxischeck
#Tailwind CSS #CSS #Frontend #Design System

Tailwind CSS v4.2 ist kein Major-Release mit Paradigmenwechsel – es schließt Lücken. Webpack wird erstmals offiziell unterstützt, vier neue Farbpaletten kommen dazu, Logical Properties erhalten vollständige Abdeckung und Typography-Utilities werden feingranularer. Wer auf ein stabiles Setup setzt, muss nicht sofort handeln. Wer neu startet oder skalierbare Systeme baut, bekommt hier solide Grundlagen.

Wer den Sprung von v3 auf v4 noch nicht mitgemacht hat: Der Überblick zu Tailwind v4.0 und der Artikel Von Utility-Salat zu Systemdenken decken die Grundlagen ab. Dieser Artikel geht davon aus, dass v4.0 bekannt ist.

Wo v4.2 ansetzt – und wo nicht

Tailwind entwickelt sich seit v4.0 in eine klare Richtung: weniger Konfiguration, näher an nativen CSS-Standards, stärkerer Fokus auf korrekte CSS-Abstraktion statt auf mehr Utility-Klassen.

v4.2 ist ein Schritt in dieser Richtung, kein Bruch. Die Änderungen lassen sich in drei Kategorien einteilen:

  • Sofort sichtbar: Neue Farbpaletten
  • Langfristig wichtig: Logical Properties, Deprecations
  • Situativ relevant: Webpack-Plugin, font-features

Webpack ist jetzt First-Class Citizen

Bisher war Tailwind und Webpack immer eine Zweckehe: Das Setup lief über PostCSS als Zwischenschicht – zusätzliche Konfiguration, ein weiterer Moving Part, unnötige Komplexität.

Das ändert sich mit @tailwindcss/webpack: Tailwind ist jetzt direkt in den Webpack-Build integriert, ohne PostCSS als Umweg.

npm install @tailwindcss/webpack
// webpack.config.js
const TailwindCSS = require('@tailwindcss/webpack');

module.exports = {
  plugins: [new TailwindCSS()],
};

Einordnung: Wer auf Vite, Turbopack oder Astro setzt, merkt davon nichts. In diesem Monorepo verwenden alle Apps @tailwindcss/vite – das Webpack-Plugin ist hier irrelevant. Für Legacy-Projekte oder bewusst Webpack-basierte Setups ist es dagegen eine echte Vereinfachung.

Wie es bei uns aussieht

Dieses Projekt nutzt @tailwindcss/vite in jeder App identisch:

// apps/homepage/astro.config.mjs (identisch in allen Apps)
import tailwind from '@tailwindcss/vite';

export default defineConfig({
  vite: {
    plugins: [tailwind()],
  },
});

Eine zentrale Entry-CSS-Datei importiert Tailwind und definiert alle Tokens:

/* shared/src/styles/tailwind.entry.css */
@import "tailwindcss";

@custom-variant dark (&:where(.dark, .dark *));

@source "../apps/*/src/**/*.{html,js,ts,tsx,jsx,vue,svelte,astro}";
@source "../shared/layouts/**/*.astro";
@source "../shared/components/**/*.{astro,svelte,vue,tsx,jsx}";

@plugin "@tailwindcss/forms" { strategy: base; }
@plugin "@tailwindcss/typography" { strategy: base; }

@theme {
  /* Alle Color-, Font- und Animation-Tokens */
}

Kein tailwind.config.js, kein PostCSS. Alles in CSS. Genau das, was v4.0 versprochen hat – und was mit v4.2 weiter konsolidiert wird.

Neue Farbpaletten: Mauve, Olive, Mist, Taupe

Das sichtbarste Feature. Tailwind hatte bisher hauptsächlich generische Neutrals – das typische Tailwind-Grau, das in tausend Projekten gleich aussieht.

Die vier neuen Paletten folgen einem anderen Ansatz: subtil gefärbte Neutrals, die sofort hochwertiger wirken, ohne eigenes Branding zu erfordern.

PaletteCharakterPasst zu
mistkühl-blau, frischSaaS, Dashboards, Tech-Produkte
taupewarm-braun, geerdetBusiness, Premium, Consulting
olivegrün-grau, natürlichNachhaltigkeit, Outdoor, Natur
mauveviolett-grau, weichModern, Creator, Lifestyle
<div class="bg-taupe-50 text-taupe-900 border border-taupe-200">
  Karte mit Premium-Neutral-Ton
</div>

Was das für bestehende Projekte bedeutet

Die neuen Farben sind Drop-in – sie kollidieren nicht mit bestehenden Klassen. Wer ein Custom-Token-System wie dieses hier nutzt, profitiert trotzdem:

/* Bestehendes Setup in diesem Projekt */
@theme {
  --color-earth: 191 111 96;  /* #bf6f60 – warmer Akzent */
  --color-tan: 204 178 143;   /* #ccb28f – sandiger Neutral */
  --color-cream: 252 242 224; /* #fcf2e0 – heller Hintergrund */
}

Die eigenen Tokens decken den Brand-Bereich ab. Die neuen Tailwind-Neutrals ergänzen als konsistente Hintergrund- und Textvarianten – ohne manuelles Feintuning. taupe passt besonders gut zu warmen Brand-Systemen wie diesem, weil der Grundton in die gleiche Richtung geht wie earth und tan.

Für neue Projekte oder Landing Pages, bei denen kein aufwändiges Token-System nötig ist, reichen die eingebauten Paletten direkt aus:

<!-- Vorher: Slate-Grau überall, wirkt generisch -->
<section class="bg-slate-50 text-slate-900">
  <p class="text-slate-600">Beschreibung</p>
</section>

<!-- Nachher: Taupe als warmer Neutral, sofort hochwertiger -->
<section class="bg-taupe-50 text-taupe-900">
  <p class="text-taupe-600">Beschreibung</p>
</section>

Einordnung: Kein Gamechanger in der Architektur, aber die Designqualität steigt ohne Aufwand. Der Trend zu subtil gefärbten Neutrals ist in UI-Design-Systemen seit einiger Zeit klar – Tailwind zieht hier nach.

Logical Properties: Das technisch wichtigste Feature

Das wird am häufigsten unterschätzt. Logical Properties ersetzen die physischen Richtungsangaben (links, rechts, oben, unten) durch richtungsabhängige Konzepte, die sich automatisch an Schreibrichtung und Layout-Kontext anpassen.

Das klassische Problem:

<!-- Alt: hardcoded direction -->
<div class="pl-4 pr-8 pt-2 pb-6">...</div>

Bei RTL-Sprachen (Arabisch, Hebräisch) müsste man das manuell spiegeln oder dir="rtl" kombinieren – fehleranfällig und schwer wartbar.

Mit Logical Properties:

<!-- Neu: richtungsabhängig -->
<div class="ps-4 pe-8 pbs-2 pbe-6">...</div>

ps bedeutet „Padding an der Start-Seite der Inline-Achse” – bei LTR ist das links, bei RTL rechts. Das Layout passt sich automatisch an.

Tailwind v4.2 deckt jetzt alle Utility-Kategorien ab:

Physisch (alt)Logisch (neu)Bedeutung
pt-*pbs-*Block-Start (oben bei horizontal)
pb-*pbe-*Block-End (unten bei horizontal)
pl-*ps-*Inline-Start (links bei LTR)
pr-*pe-*Inline-End (rechts bei LTR)
w-*inline-*Größe auf der Inline-Achse
h-*block-*Größe auf der Block-Achse

Wo Logical Properties schon im Einsatz sind – ohne Tailwind

Interessant: In vielen Projekten werden Logical Properties längst verwendet – nur nicht über Tailwind-Utilities, sondern direkt in CSS. Dieses Projekt macht das bereits an mehreren Stellen:

/* shared/src/styles/tailwind.entry.css */
.container-custom {
  max-width: 72rem;
  margin-inline: auto;       /* ← logisch */
  padding-inline: clamp(1rem, 3vw, 2rem);  /* ← logisch */
}

.section-padding {
  padding-block: clamp(3rem, 6vw, 5rem);   /* ← logisch */
}

margin-inline, padding-inline, padding-block – das sind exakt die CSS-Properties, die Tailwind v4.2 jetzt als Utilities anbietet. Die Komponenten nutzen die richtige Architektur, nur ohne die Utility-Klassen.

Mit v4.2 ließe sich dasselbe direkt im Markup schreiben:

<!-- Statt einer Custom-Klasse .container-custom -->
<div class="max-w-6xl mx-auto px-4 md:px-8">
  <!-- wird zu (logisch) -->
</div>
<div class="max-inline-6xl mis-auto pis-4 md:pis-8">
  <!-- Layout passt sich automatisch an LTR/RTL an -->
</div>

Ob man die Custom-Klassen behält oder auf Utilities umstellt, ist Geschmackssache. Entscheidend ist: Tailwind und das eigene CSS sprechen jetzt die gleiche Sprache.

Einordnung: Für Projekte ohne i18n-Anforderungen ist das „nice to have”. Für skalierbare Systeme oder Projekte, die Mehrsprachigkeit planen, ist die konsequente Nutzung von Logical Properties von Anfang an die sauberere Architektur.

font-features Utilities

Endlich sauber in Tailwind nutzbar: OpenType Font Features für typografische Feinsteuerung.

<!-- Ligaturen aktivieren -->
<p class="font-features-liga">fi fl ff</p>

<!-- Tabellarische Zahlen (gleiche Breite, ideal für Tabellen) -->
<td class="font-features-tnum">1.234,56 €</td>

<!-- Small Caps -->
<span class="font-features-smcp">Abkürzungen</span>

Wo das im Projekt relevant wäre

Dieses Projekt verwendet Onest als Hauptschrift mit einem aufwändigen Text-Size-Token-System:

@theme {
  --font-onest: Onest, system-ui, sans-serif;
  --text-base: 1.125rem;
  --text-base--line-height: 1.7;
  --text-base--letter-spacing: -0.017em;
  /* ... 11 Stufen von xs bis 7xl */
}

Die Schrift unterstützt tabellarische Zahlen – bisher müsste man das per Custom-CSS lösen:

/* Alt: manuell */
.counter-number {
  font-feature-settings: "tnum" 1;
}
<!-- Neu: direkt als Utility -->
<span class="text-3xl font-semibold font-features-tnum">2.847</span>

Für die Counter-Zahlen auf der Homepage (Hero-Bereich mit Projektstatistiken) oder Preistabellen auf Service-Seiten ist font-features-tnum ein kleiner, aber spürbarer Qualitätsgewinn: Zahlen richten sich sauber untereinander aus, ohne dass die Ziffernbreite springt.

Einordnung: Klein, aber nützlich im Detail. Besonders relevant für Dashboards, Preistabellen und überall dort, wo Zahlen in Spalten stehen.

Deprecation: start-* / end-* → inline-s-* / inline-e-*

Die alten positionsbezogenen Klassen start-* und end-* werden durch inline-s-* und inline-e-* ersetzt – konsistent mit der Logical-Properties-Systematik.

<!-- Alt (deprecated) -->
<div class="start-4 end-8">...</div>

<!-- Neu -->
<div class="inline-s-4 inline-e-8">...</div>

In diesem Projekt werden start-* / end-* als Tailwind-Position-Utilities nicht verwendet – die Migration betrifft hier also nichts. Wer sie in anderen Projekten nutzt: Migration ist automatisierbar, kein Drama.

Das Upgrade in der Praxis

Das Astro v6 Template – ein Open-Source-Monorepo-Starter mit Astro 6, Svelte 5 und Cloudflare – läuft bereits auf Tailwind 4.2.2. Die Konfiguration zeigt, wie ein v4.2-Setup ohne Altlasten aussieht:

/* apps/starter/src/styles/app.css */
@import "tailwindcss";
@import "@astro-v6/shared/styles/global";
@import "@astro-v6/shared/styles/theme";

/* Shared-Package für Tailwind-Klassen scannen (kein Alias möglich, muss relativ sein) */
@source "../../../../shared/src";
/* shared/src/styles/theme.css – OKLCH Tokens als Tailwind-Theme */
@theme {
  --color-bg: oklch(98% 0 0);
  --color-text: oklch(18% 0 0);
  --color-accent: oklch(48% 0.16 220);
  --color-accent-hover: oklch(38% 0.12 220);
  --color-border: oklch(92% 0 0);
  --shadow-sm: 0 1px 2px 0 oklch(0% 0 0 / 0.05);
  --radius-sm: 0.125rem;
  --radius-md: 0.375rem;
}

Kein tailwind.config.js, kein PostCSS, keine JavaScript-Konfiguration. Die Token-Definition wandert komplett in CSS – mit OKLCH statt RGB für gleichmäßigere Farbverläufe. Die semantischen Tokens (--color-bg, --color-text, --color-accent) passen sich über CSS Custom Properties in variables.css an: Dort überschreibt die .dark-Klasse die Werte für den Dark Mode.

Was bei einem v4.0 → v4.2 Upgrade passiert

Wer schon auf v4.0 oder v4.1 ist, bekommt v4.2 ohne Reibung. Die neuen Features sind additiv:

  • Neue Farbpaletten sind sofort verfügbar, aber kollidieren mit nichts Bestehendem
  • Logical Property Utilities sind neu, erzwingen aber keine Migration
  • font-features sind zusätzliche Klassen
  • Das Webpack-Plugin ist optional

Im Template war das Update von v4.1 auf v4.2 eine Zeile im pnpm-workspace.yaml – kein Breaking Change, kein Build-Problem.

Wer noch auf v3 steht, hat einen größeren Sprung vor sich – dafür gibt es den v4.0-Migrationsleitfaden.

Was v4.2 über die Richtung von Tailwind verrät

Die Einzelfeatures sind jeweils überschaubar. Interessanter ist das Muster dahinter:

Tailwind bewegt sich weg von „mehr Utility-Klassen” hin zu „korrekte CSS-Abstraktion”. Logical Properties, font-features, Inline/Block-Sizing – das sind keine Tailwind-Erfindungen, sondern native CSS-Konzepte, die jetzt als Utilities zugänglich werden.

Das @theme-System mit CSS Custom Properties (seit v4.0) geht in die gleiche Richtung. Die Konfiguration wandert von JavaScript nach CSS. Die Build-Kette wird dünner. Tailwind wird weniger Framework und mehr Beschleuniger für modernes CSS.

Für Projekte, die bereits auf v4 setzen und @theme nutzen, ist das eine Bestätigung: Die Architekturentscheidung war richtig. Für Teams, die noch auf v3 stehen, wird der Abstand größer – aber die Migration wird nicht schwieriger, nur der Anreiz stärker.

Lohnt sich das Upgrade?

Upgrade lohnt sich, wenn:

  • du neu startest und saubere Architektur von Anfang an willst
  • du i18n planst oder skalierbare UI-Systeme baust
  • du Webpack einsetzt und PostCSS loswerden möchtest
  • du bereits auf v4.0/v4.1 bist – dann ist v4.2 risikolos

Upgrade ist egal, wenn:

  • dein Setup stabil läuft und keine neuen Features gebraucht werden
  • du kurzlebige Projekte baust, bei denen Architektur sekundär ist

Sofort nutzbar ohne Risiko:

  • Neue Farbpaletten: Drop-in, keine bestehenden Klassen betroffen
  • font-features: Zusätzliche Utilities, keine Konflikte

Zukunftssyntax, die sich lohnt zu lernen:

  • Logical Properties: Jetzt verstehen, schrittweise einführen
  • Inline/Block-Sizing: Konsistent mit der Logical-Properties-Logik