Tailwind CSS 4.3 in Produktion: Container-Size-Queries im Detail

Tailwind CSS v4.3.3 wurde am 16. Juli getaggt, elf Bugfixes, keine neuen Utilities. Das ist eine unspektakuläre Meldung, aber genau die Art von Unspektakulärem, die für Produktionsentscheidungen zählt. Seit dem Feature-Release v4.3.0 im Mai sind drei reine Wartungs-Releases erschienen, ein v4.4 gibt es bislang nicht. Die 4.3-Linie ist damit in dem Zustand, den man für Kundenprojekte will: ausgereift, ohne offene Baustellen.

Wie ich im Artikel zu Twig 3.27 und Tailwind 4.3 im Juni bereits kurz angeschnitten habe, waren die Scrollbar-Utilities das Feature, das die meisten Schlagzeilen bekam. Dieser Artikel geht tiefer, vor allem in die Container-Size-Queries, die für komponentenbasierte Layouts der eigentlich relevantere Baustein sind.

Tailwind CSS 4.3: Feature-Übersicht

Warum @container-size mehr bringt als es zunächst klingt

Container-Queries in Tailwind gab es schon vor 4.3, allerdings ausschließlich auf Basis der Breite. Für viele Layout-Probleme reicht das nicht. Eine Karten-Komponente, die je nach verfügbarer Höhe unterschiedlich viel Content anzeigen soll, oder ein Sidebar-Widget, das bei wenig vertikalem Platz kompakter rendern muss, ließ sich bisher nur über JavaScript oder ResizeObserver lösen.

<!-- Container als Size-Container markieren -->
<div class="@container-size/card h-[300px] border border-slate-200">
<!-- Reagiert auf die tatsächliche Höhe des Containers -->
<p class="text-slate-600 @[block-size>200px]/card:text-emerald-600 font-semibold">
Diese Farbe ändert sich abhängig von der Container-Höhe
</p>
</div>

<!-- Kombiniert mit normaler Breiten-Query: -->
<div class="@container/card @container-size/card">
<div class="@sm:flex @[block-size>150px]:gap-4">
<!-- reagiert auf Breite UND Höhe gleichzeitig -->
</div>
</div>

Der Unterschied zur breitenbasierten Query ist keine Kosmetik. Ein @container ohne -size-Suffix optimiert intern, indem er nur Inline-Size-Änderungen beobachtet, was performanter ist, aber Höhenänderungen ignoriert. @container-size beobachtet beide Dimensionen, kostet dafür etwas mehr Rendering-Aufwand. Für die meisten UI-Komponenten ist das kein spürbares Problem, für sehr große Listen mit vielen gleichzeitig sichtbaren Size-Containern lohnt sich ein Blick auf die Performance in der Praxis.

Was zoom-*, tab-* und die neuen @variant-Formen bringen

Wofür sind zoom-* und tab-* im Alltag gut?

zoom-* mappt direkt auf die CSS-zoom-Property, die inzwischen von allen relevanten Browsern unterstützt wird. Für skalierte Vorschau-Kacheln, etwa in einem Design-System-Showcase oder einer Thumbnail-Vorschau, ersetzt das bisherige transform: scale()-Konstruktionen, die zusätzlich das Layout-Flow-Verhalten beeinflussten.

<!-- Vorher: transform beeinflusst den Layout-Flow -->
<div class="scale-75 origin-top-left">...</div>

<!-- Jetzt: zoom skaliert ohne Flow-Nebenwirkungen -->
<div class="zoom-75">...</div>

<!-- tab-* für Code-Blöcke: -->
<pre class="tab-2">...</pre>
<!-- Arbiträre Werte: tab-[12px] oder CSS-Variable: tab-(--tab-size) -->

tab-* steuert die tab-size-Property für vorformatierten Text. Für Code-Blöcke in technischer Dokumentation oder Blog-Artikeln mit eingebettetem Code ist das ein kleines, aber willkommenes Detail, das vorher eine eigene CSS-Regel brauchte.

Was ändert sich bei der @variant-Syntax?

Stacked und Compound Variants lassen sich jetzt direkt in CSS schreiben, nicht mehr nur als Klassenname-Kombination im Markup.

/* Stacked: mehrere Zustände nacheinander */
@variant hover:focus {
outline: 2px solid var(--color-blue-500);
}

/* Compound: mehrere Zustände als Alternative */
@variant hover, focus {
background-color: var(--color-slate-50);
}

Für Teams, die eigene Utility-Definitionen pflegen, ist zusätzlich die neue --default()-Unterstützung relevant. Funktionale Utilities können jetzt einen Fallback-Wert definieren, sodass eine bare Klasse wie tab ohne Suffix auf einen sinnvollen Standardwert auflöst, statt undefiniert zu bleiben.

Lohnt sich das Upgrade für ein laufendes Projekt?

Was macht die 4.3-Linie produktionsreif?

Drei reine Wartungs-Releases nach dem Feature-Release sind ein gutes Signal. v4.3.1 im Juni brachte Fixes für die Utility-Engine und Node-26-Kompatibilität, v4.3.2 und v4.3.3 folgten mit weiteren Detailkorrekturen, ohne neue Utilities einzuführen. Für Agenturen, die Kundenprojekte auf stabilen Versionen aufsetzen, ist das die Bestätigung, dass die größeren Kinderkrankheiten durchlaufen sind.

Wer den offiziellen Upgrade-Befehl nutzt, profitiert zusätzlich von verbesserten Canonicalizer-Fixes: signifikante Unterstriche in arbiträren Werten bleiben erhalten, ursprüngliche Einheiten werden nicht mehr unnötig normalisiert, und Inline-Style-Attribute werden beim Upgrade nicht mehr automatisch in Tailwind-Klassen umgeschrieben.

# Upgrade auf die aktuelle 4.3-Version
$ npm install tailwindcss@latest

# Für Projekte mit dem offiziellen Upgrade-Tool:
$ npx @tailwindcss/upgrade

# Danach: visuellen Regressionstest gegen zentrale Views laufen lassen,
# besonders bei Projekten mit vielen arbiträren Werten

Zusammenfassung

Tailwind CSS 4.3.3 ist ein reines Bugfix-Release, die 4.3-Linie gilt als ausgereift. Kein v4.4 in Sicht.

@container-size ist der praktisch relevanteste Baustein aus 4.3 für komponentenbasierte Layouts, weil er Höhen-Constraints direkt in CSS löst, wo vorher meist JavaScript nötig war.

zoom-*, tab-* und die neuen @variant-Formen schließen kleinere, aber wiederkehrende Lücken, besonders relevant für Teams mit eigenen Utility-Definitionen.

Der Upgrade-Befehl hat verbesserte Canonicalizer-Fixes für Projekte mit vielen arbiträren Werten.