Tailwind Container Query Units: cqw, cqh und cqi praktisch einsetzen
AI generated
tw
Tailwind CSS · Container Queries · Responsive Design
Container Query Units in Tailwind
cqw, cqh und cqi praktisch einsetzen, statt Komponenten an den Viewport zu binden

Viewport-Einheiten wie vw und vh haben ein strukturelles Problem: Sie kennen nur die Größe des Browserfensters, nicht die Größe des Containers, in dem eine Komponente tatsächlich lebt. Container Query Units lösen genau das, indem sie Größen relativ zum nächsten Container mit gesetztem container-type berechnen. Zusammen mit den nativen @container-Utilities aus Tailwind v4 lassen sich damit Komponenten bauen, die sich unabhängig vom umgebenden Layout korrekt verhalten, egal ob sie in einer schmalen Sidebar oder einem breiten Hauptbereich landen.

16 Min. Lesezeit cqw · cqh · cqi @container Tailwind v4

1. Was Container Query Units sind und welches Problem sie lösen

Container Query Units sind Längeneinheiten, die sich nicht auf das Browserfenster beziehen, sondern auf die Größe des nächsten Vorfahren-Elements, das als Query-Container markiert wurde. Während vw und vh immer die volle Breite und Höhe des sichtbaren Viewports als Bezugsgröße nehmen, unabhängig davon, wo eine Komponente im Layout tatsächlich platziert ist, berechnen sich cqw und cqh relativ zu genau dem Container, in dem das Element steckt. Das klingt zunächst nach einer kleinen Nuance, verändert aber grundlegend, wie wiederverwendbare Komponenten gebaut werden können.

Das klassische Problem zeigt sich bei einer Karten-Komponente, die sowohl in einer schmalen Sidebar als auch in einem breiten Hauptbereich einer Seite auftauchen soll. Mit Viewport-Einheiten bekommt die Karte in beiden Fällen dieselbe Schriftgröße, weil der Viewport identisch bleibt, obwohl der verfügbare Platz komplett unterschiedlich ist. Mit Container Query Units passt sich die Schriftgröße dagegen automatisch an die tatsächliche Breite des jeweiligen Containers an, unabhängig davon, wie groß das Browserfenster gerade ist oder wie tief die Komponente im Layout verschachtelt wurde.

2. cqw, cqh, cqi, cqb, cqmin und cqmax im Detail

cqw entspricht einem Prozent der Container-Breite, cqh einem Prozent der Container-Höhe, jeweils bezogen auf den nächsten Vorfahren mit gesetztem container-type. Daneben gibt es die logischen Varianten cqi (inline-size, also die Breite in horizontaler Schreibrichtung) und cqb (block-size, die Höhe entlang der Blockrichtung), die bei vertikalen Schreibrichtungen wichtig werden, im üblichen Alltag mit lateinischer Schrift aber meist deckungsgleich mit cqw und cqh sind. In der Praxis wird cqi gegenüber cqw oft bevorzugt, weil es sich sauberer mit logischen Eigenschaften wie margin-inline kombiniert.

cqmin und cqmax nehmen jeweils den kleineren beziehungsweise größeren Wert aus Breite und Höhe des Containers, ähnlich wie vmin und vmax es für den Viewport tun. Das ist nützlich, wenn eine Größe weder rein von der Breite noch rein von der Höhe abhängen soll, etwa bei einem quadratischen Icon-Container, dessen Icon-Größe sich an der jeweils kleineren Dimension orientieren soll, damit es nie über den Rand hinausragt, egal ob der Container eher breit oder eher hoch ausfällt.


/* Basis-Einheiten */
.karte-titel {
  font-size: 5cqi;   /* 5% der Container-Inline-Größe */
}

.karte-icon {
  width: 8cqmin;      /* orientiert sich an der kleineren Container-Dimension */
  height: 8cqmin;
}

3. container-type setzen: die Voraussetzung für jede Container Query Unit

Container Query Units funktionieren nur innerhalb eines Elements, dessen Vorfahre explizit als Container markiert wurde, über die CSS-Eigenschaft container-type. Ohne diese Markierung fallen die Einheiten auf ihr Fallback-Verhalten zurück und verhalten sich faktisch wie 0, was in der Praxis meist zu einem unsichtbaren oder falsch skalierten Element führt. In Tailwind v4 reicht die Utility-Klasse @container auf dem gewünschten Vorfahren-Element, um container-type: inline-size zu setzen, der in den meisten Fällen passende Wert für horizontal skalierende Layouts.

Wichtig ist, dass der Container-Vorfahre nicht zwangsläufig das direkte Elternelement sein muss, sondern der nächste Vorfahre in der DOM-Hierarchie ist, der die Markierung trägt. Das erlaubt es, einen Container weiter oben im Baum zu setzen und mehrere verschachtelte Kindelemente gleichzeitig von denselben Container Query Units profitieren zu lassen, ohne dass jede einzelne Ebene dazwischen selbst zum Container erklärt werden muss. Genau diese Flexibilität macht Container Queries für komplexe, mehrstufige Komponentenstrukturen so praktikabel.

4. Praxisbeispiel: Schriftgröße in einer wiederverwendbaren Karten-Komponente

Eine Produktkarte, die sowohl in einer schmalen 280-Pixel-Sidebar als auch in einem breiten 900-Pixel-Hauptbereich dargestellt wird, braucht in beiden Kontexten eine passend proportionierte Schrift. Mit @container auf dem umschließenden Grid-Element und cqi-basierten Schriftgrößen auf dem Kartentitel skaliert die Typografie automatisch mit der tatsächlich verfügbaren Breite, ohne dass für jede mögliche Platzierung eine eigene Breakpoint-Regel geschrieben werden muss.

Der entscheidende Unterschied zu einer reinen Media-Query-Lösung zeigt sich, sobald dieselbe Karte gleichzeitig an zwei Stellen der Seite eingebunden wird, etwa einmal in der Sidebar und einmal im Hauptbereich. Eine Media Query kann nur auf die Größe des gesamten Viewports reagieren und würde beiden Instanzen dieselbe Schriftgröße zuweisen, selbst wenn ihre Container komplett unterschiedlich breit sind. Container Query Units berechnen dagegen für jede Instanz individuell relativ zu ihrem eigenen Container, wodurch beide Karten gleichzeitig korrekt proportioniert bleiben.