Container Query Units: cqw, cqh, cqi und cqb praktisch einsetzen

1. Was Container Query Units sind und warum sie Viewport-Einheiten ergänzen

Die Einheiten cqw, cqh, cqi und cqb verhalten sich syntaktisch wie vw und vh, beziehen sich aber nicht auf das Browserfenster, sondern auf die Größe des nächstgelegenen Query-Containers. Ein 1cqw entspricht einem Prozent der Breite dieses Containers, nicht der Seite. Das klingt nach einer kleinen Verschiebung der Bezugsgröße, ändert aber grundlegend, wie eine Komponente über verschiedene Layout-Kontexte hinweg skaliert.

Vor Container Query Units war eine Komponente entweder an den Viewport gekoppelt, was in einer schmalen Sidebar zu winzigem Text führte, oder an feste Pixelwerte, die in keinem Kontext wirklich passten. Mit cqi und den verwandten Einheiten skaliert die Komponente relativ zu dem Platz, der ihr tatsächlich zur Verfügung steht, egal ob sie in einer Sidebar, einem Modal oder einem Vollbreiten-Grid landet.

2. Grundvoraussetzung: container-type auf dem Elternelement setzen

Container Query Units funktionieren nur innerhalb eines Elements, das mit container-type zu einem Query-Container erklärt wurde. Ohne diese Deklaration fallen die Einheiten auf den nächsten übergeordneten Container zurück oder verhalten sich wie 0, wenn gar keiner existiert. Am häufigsten kommt container-type: inline-size zum Einsatz, weil es nur die Inline-Richtung (meist die Breite) überwacht und teurer zu berechnende Block-Größen-Überwachung vermeidet.

Ein optionaler container-name erlaubt es, mehrere verschachtelte Container gezielt anzusprechen, falls eine Komponente sich nicht auf den nächstgelegenen, sondern auf einen weiter außen liegenden Container beziehen soll. Für die meisten praktischen Fälle reicht jedoch der implizite Bezug auf den nächsten Container, ganz ohne explizite Namensangabe in der Deklaration der Einheit selbst.

.card-container {
  container-type: inline-size;
  container-name: card;
}

.card {
  /* Schriftgröße skaliert mit der Container-Breite, nicht dem Viewport */
  font-size: clamp(0.95rem, 0.85rem + 1.5cqi, 1.25rem);
  padding: clamp(0.75rem, 2cqw, 1.5rem);
}

3. Schriftgrößen mit cqi skalieren: das Card-Beispiel im Detail

cqi steht für container query inline size und bezieht sich auf die Inline-Achse des Containers, in einer klassischen horizontalen Schreibrichtung also auf dessen Breite. Kombiniert mit clamp() entsteht eine Schriftgröße, die zwischen einem Minimal- und einem Maximalwert weich mitwächst, sobald der Container breiter wird, aber niemals unlesbar klein oder unangenehm groß ausfällt.

Der Vorteil gegenüber reinen Viewport-Einheiten zeigt sich sofort in einem Dashboard-Layout: Eine Statistik-Karte, die in einer drei Spalten breiten Übersicht sitzt, bekommt automatisch eine kleinere Schrift als dieselbe Karte, wenn sie allein in einer Detailansicht über die volle Breite gerendert wird, obwohl der Viewport in beiden Fällen identisch bleibt. Die Komponente reagiert auf ihren tatsächlichen Platz, nicht auf die Fenstergröße.

4. Abstände und Innenraster mit cqw und cqi konsistent skalieren

Nicht nur Schriftgrößen profitieren von Container Query Units, auch padding, gap und margin lassen sich relativ zur Containerbreite definieren. Das hält das Verhältnis zwischen Text und Weißraum über verschiedene Containerbreiten hinweg proportional stabil, statt bei einem festen Pixelwert entweder zu eng oder zu großzügig zu wirken.

Ein bewährtes Muster ist, den Innenabstand einer Karte mit clamp(1rem, 3cqw, 2rem) zu definieren: In einer sehr schmalen Sidebar bleibt der Abstand bei einem Rem, wächst dann proportional mit der Containerbreite mit und deckelt bei zwei Rem, sobald der Container breit genug ist. So bleibt das Layout in jedem Kontext ausgewogen, ohne dass für jede Breakpoint-Stufe eine eigene Media Query nötig wird.

.stat-card {
  container-type: inline-size;
}

.stat-card__inner {
  padding: clamp(1rem, 3cqw, 2rem);
  gap: clamp(0.5rem, 1.5cqw, 1rem);
  display: flex;
  flex-direction: column;
}

.stat-card__value {
  font-size: clamp(1.5rem, 1rem + 4cqi, 2.5rem);
  font-weight: 700;
}

5. cqb und cqh: die Block-Achse und wann sie wirklich relevant wird

cqb (container query block size) bezieht sich auf die Block-Achse des Containers, in horizontaler Schreibrichtung also auf dessen Höhe. cqh ist das direkte Pendant zu vh und bezieht sich immer auf die Höhe, unabhängig von der Schreibrichtung. Beide setzen voraus, dass container-type auf size statt nur inline-size steht, damit der Browser überhaupt die Blockgröße des Containers überwacht.

In der Praxis kommen diese beiden Einheiten seltener zum Einsatz als cqw und cqi, weil Höhen in Weblayouts meist vom Inhalt bestimmt werden statt umgekehrt. Sinnvoll werden sie bei fest dimensionierten Containern, etwa einem Video-Player mit definierter Höhe, in dem Steuerelemente proportional zur Player-Höhe skalieren sollen, oder bei Karten in einem CSS-Grid mit fixierter Zeilenhöhe.

6. Praktisches Rezept: eine Komponente, die sich in jedem Kontext selbst anpasst

Das eigentliche Versprechen von Container Query Units zeigt sich, wenn dieselbe Komponente unverändert in mehrere Layout-Kontexte kopiert wird. Eine Produktkarte, die sowohl in einer schmalen Sidebar-Empfehlung als auch in einem breiten Grid der Kategorieseite auftaucht, braucht dann keine kontextspezifischen Modifier-Klassen mehr, weil sie ihre Typografie und ihre Abstände selbst aus der verfügbaren Breite ableitet.

Der Aufbau bleibt dabei denkbar einfach: Der äußere Wrapper bekommt container-type: inline-size, die inneren Elemente nutzen ausschließlich relative Einheiten wie cqi und cqw in Kombination mit clamp() für sinnvolle Ober- und Untergrenzen. Damit lässt sich ein komplettes Komponenten-System bauen, bei dem jede einzelne Komponente selbstständig weiß, wie sie sich in engem oder großzügigem Platz zu verhalten hat.