container-type: size Queries im Detail: Größenbasierte Containerabfragen richtig einsetzen

1. Warum container-type size mehr ist als inline-size

Die meisten Einführungen in Container Queries beschränken sich auf container-type: inline-size, weil dieser Wert für die häufigsten Layoutprobleme, responsive Karten und Komponenten basierend auf verfügbarer Breite, vollkommen ausreicht. container-type: size geht einen entscheidenden Schritt weiter: Es erlaubt Abfragen sowohl nach Breite als auch nach Höhe des Containers, also echte zweidimensionale Container Queries. Das öffnet neue Anwendungsfälle, etwa Komponenten, die sich an die verfügbare vertikale Höhe in einem Sidebar-Panel oder einem Dashboard-Widget anpassen müssen.

Der Preis für diese zusätzliche Fähigkeit ist strengere Containment: container-type: size erzwingt sowohl Größen- als auch Layout-Containment auf dem Element, was bedeutet, dass der Container seine eigene Größe nicht mehr aus dem Inhalt ableiten darf. Ohne explizite Höhenangabe kollabiert ein solcher Container auf eine Höhe von null Pixeln, ein Verhalten, das viele Entwickler beim ersten Einsatz von container-type: size überrascht und für den berüchtigten "leeren Container"-Bug sorgt.

2. Die drei Werte von container-type im Überblick

Die Eigenschaft container-type kennt drei Werte. normal ist der Standardwert, das Element wird kein Container Query Container, verhält sich also wie jedes andere Element. inline-size aktiviert Containment nur entlang der Inline-Achse, in horizontalen Schreibrichtungen also die Breite, und erlaubt Abfragen nach dieser einen Dimension. container-type: size aktiviert Containment entlang beider Achsen, Inline- und Block-Richtung, und erlaubt Abfragen nach Breite und Höhe gleichzeitig.

Ein zentrales Detail, das oft übersehen wird: Alle drei Werte lassen sich nicht beliebig mischen, ein Element ist entweder gar kein Container, ein reiner Breiten-Container, oder ein vollständiger Größen-Container. Es gibt keine Zwischenstufe wie "nur Höhen-Containment ohne Breiten-Containment" über container-type allein, wer ausschließlich die Höhe abfragen möchte, muss trotzdem container-type: size verwenden und kann in der zugehörigen @container-Regel gezielt nur nach min-height oder vergleichbaren Höhen-Bedingungen fragen.

/* inline-size: only width containment, height derives from content normally */
.card-container {
  container-type: inline-size;
  container-name: card;
}

/* size: containment on BOTH axes, height must now be explicit */
.widget-container {
  container-type: size;
  container-name: widget;
  height: 240px; /* required, otherwise this container collapses to 0px height */
}

@container widget (min-height: 200px) {
  .widget-title { font-size: 1.25rem; }
}

3. Explizite Containment und ihre Nebenwirkungen

Der CSS Containment Standard, auf dem Container Queries aufbauen, definiert mehrere Containment-Typen: size, layout, style und paint. container-type: size setzt intern contain: size layout style, was dem Browser erlaubt, das Element beim Rendering vollständig zu isolieren, ohne dass Änderungen im Inneren des Containers das Layout außerhalb beeinflussen können. Diese Isolation ist die Grundlage dafür, dass der Browser überhaupt effizient Container Queries auswerten kann, ohne endlose Rückkopplungsschleifen zwischen Inhalt und Abfrage zu riskieren.

Die Nebenwirkung von contain: size ist, dass der Inhalt des Containers komplett ignoriert wird, wenn der Browser dessen Größe berechnet. Ein container-type: size Container mit variabler Textmenge im Inneren wächst nicht automatisch mit dem Text mit, der Text wird stattdessen abgeschnitten oder läuft über, je nach overflow-Einstellung. Diese Nebenwirkung ist beabsichtigt und keine Fehlfunktion, sie ist der Grund, warum container-type: size nur für Layoutbereiche mit bekannter oder extern kontrollierter Größe geeignet ist, nicht für Bereiche, deren Höhe vom Inhalt abhängen soll.

4. Feste Höhen definieren, damit der Container nicht kollabiert

Die praktische Konsequenz aus dem vorherigen Abschnitt: Jeder container-type: size Container braucht eine explizite Höhenquelle, die unabhängig vom Inhalt existiert. Das kann eine feste Pixel- oder Rem-Höhe sein, eine Höhe über aspect-ratio in Kombination mit einer festen Breite, oder eine Höhe, die durch ein umgebendes Grid- oder Flexbox-Layout mit height: 100% vorgegeben wird. Ohne eine dieser Quellen bleibt der Container bei null Pixeln Höhe, und jeglicher Inhalt wird de facto unsichtbar, weil der Container keine Ausdehnung hat, über die hinaus gerendert werden könnte.

Ein bewährtes Muster in Grid-Layouts: Die übergeordnete Grid-Zelle bekommt über grid-template-rows eine explizite Höhe zugewiesen, das Kind-Element mit container-type: size erhält height: 100%, um diese Höhe zu übernehmen. So bleibt die Höhenlogik im Grid-System, während die Container-Query-Logik ausschließlich für die interne Anpassung des Inhalts zuständig ist. Diese Trennung verhindert, dass container-type: size versehentlich zur alleinigen Quelle der Layouthöhe wird, was schnell zu unvorhersehbarem Verhalten führt.

/* PROBLEM: no explicit height source, container collapses to 0px */
.broken-widget {
  container-type: size;
  /* height is derived from content, but content is ignored under size containment */
}

/* SOLUTION 1: explicit fixed height */
.widget-fixed {
  container-type: size;
  height: 320px;
}

/* SOLUTION 2: height inherited from a parent grid row */
.dashboard-grid {
  display: grid;
  grid-template-rows: 200px 300px; /* explicit row heights */
}
.dashboard-grid > .widget-in-grid {
  container-type: size;
  height: 100%; /* inherits the row's explicit height */
}

5. Block-Size Queries: wann sie wirklich gebraucht werden

Block-Size Queries, also Abfragen nach der Höhe eines Containers in horizontalen Schreibrichtungen, sind seltener nötig als Inline-Size Queries, aber in bestimmten Szenarien unverzichtbar. Ein typisches Beispiel ist ein Video-Player-Overlay, das seine Steuerelemente kompakter darstellen muss, sobald der verfügbare vertikale Platz unter einen bestimmten Schwellenwert fällt, unabhängig von der Breite. Ein zweites Beispiel sind Sidebar-Widgets in Dashboard-Anwendungen, bei denen Nutzer Panels frei in der Höhe verändern können und die Komponente darauf reagieren muss, welche Detailtiefe noch sinnvoll darstellbar ist.

Der entscheidende Unterschied zu Inline-Size Queries: Während die verfügbare Breite meist relativ stabil und durch das übergeordnete responsive Grid vorgegeben ist, ist die verfügbare Höhe in vielen Layouts dynamischer und schwerer vorherzusagen, etwa bei variabler Fensterhöhe oder Nutzer-Resizing. container-type: size Block-Size-Abfragen sollten deshalb konservativ eingesetzt werden, nur dort, wo tatsächlich ein klarer, wiederholbarer Anwendungsfall vorliegt, nicht als pauschaler Ersatz für Inline-Size Queries.

.video-controls-container {
  container-type: size;
  container-name: player;
  height: 100%; /* inherited from the video player wrapper */
}

/* React to available vertical space, not just width */
@container player (max-height: 120px) {
  .video-controls {
    flex-direction: row;
    gap: 0.25rem;
  }
  .video-controls .label-text {
    display: none; /* icons only when vertical space is tight */
  }
}

@container player (min-height: 200px) {
  .video-controls {
    flex-direction: column;
    gap: 0.75rem;
  }
}

6. container-type size mit aspect-ratio kombinieren

Eine der elegantesten Lösungen für das Höhen-Kollaps-Problem ist die Kombination von container-type: size mit aspect-ratio. Statt eine feste Pixel-Höhe zu definieren, die bei responsiven Breiten unpassend werden kann, definiert man eine feste Breite und ein Seitenverhältnis über aspect-ratio: 16 / 9, woraus der Browser die Höhe automatisch berechnet, unabhängig vom internen Inhalt. Diese berechnete Höhe existiert unabhängig vom Containment und kollabiert deshalb nicht.

Dieses Muster eignet sich besonders für Medien-Karten, Video-Thumbnails und Produktbilder-Container, bei denen ein konsistentes Seitenverhältnis über verschiedene Bildschirmgrößen hinweg gewünscht ist, gleichzeitig aber sowohl Breiten- als auch Höhen-basierte Container Queries für die interne Anordnung von Badges, Überschriften und Call-to-Action-Buttons benötigt werden. container-type: size in Kombination mit aspect-ratio liefert damit vorhersagbare Höhen ohne manuelle Breakpoint-Pflege.

.media-card-container {
  container-type: size;
  container-name: mediacard;
  width: 100%;
  aspect-ratio: 16 / 9; /* height is derived from width, never from content */
}

/* Both width and height conditions become available */
@container mediacard (min-width: 400px) and (min-height: 220px) {
  .media-card-overlay {
    padding: 1.5rem;
    font-size: 1.125rem;
  }
}
@container mediacard (max-width: 399px) {
  .media-card-overlay {
    padding: 0.5rem;
    font-size: 0.875rem;
  }
}

7. Style Queries und container-type size zusammen nutzen

Style Queries, abgefragt über @container style(--variant: compact), funktionieren unabhängig vom gewählten container-type-Wert, lassen sich aber sinnvoll mit container-type: size kombinieren, wenn eine Komponente sowohl auf ihre eigene Größe als auch auf einen über Custom Properties gesetzten Modus reagieren soll. Ein Dashboard-Widget könnte etwa gleichzeitig auf die verfügbare Höhe reagieren, um Inhalte auszublenden, und auf eine per Custom Property gesetzte Variante, um zwischen einer Diagramm- und einer Tabellen-Darstellung umzuschalten.

Die Kombination beider Abfragearten erlaubt granulare, aber wartbare Komponentenlogik: Größenbasierte Anpassungen bleiben in der einen @container-Regelgruppe, zustandsbasierte Anpassungen in einer anderen, während beide denselben, über container-type: size etablierten Container referenzieren. Diese Trennung von Größen- und Zustandslogik verhindert unübersichtliche, verschachtelte Bedingungen innerhalb einer einzigen Regel.

8. Performance-Aspekte: Containment-Kosten und Rekalkulation

Die durch container-type: size erzwungene Containment ist grundsätzlich performancefreundlich, weil sie dem Browser erlaubt, Layoutberechnungen auf den Container zu isolieren, statt den gesamten Dokumentbaum bei jeder Änderung neu zu bewerten. Diese Isolation reduziert die Kosten von Reflows in großen, komplexen Layouts erheblich, besonders wenn viele unabhängige Container gleichzeitig auf der Seite vorhanden sind, etwa in einem Dashboard mit zahlreichen Widgets.

Ein Performance-Risiko entsteht, wenn Entwickler container-type: size großzügig auf viele verschachtelte Ebenen anwenden, ohne die tatsächliche Notwendigkeit zu prüfen. Jede zusätzliche Containment-Grenze erzeugt einen eigenen Formatierungskontext, was in Maßen unproblematisch ist, bei exzessiver Verschachtelung aber unnötigen Overhead erzeugt. Die Empfehlung lautet, container-type: size gezielt für Komponenten mit tatsächlichem Bedarf an Höhen-Abfragen einzusetzen und für alle anderen Fälle bei inline-size zu bleiben, das einen geringeren Containment-Aufwand erfordert.

9. container-type size im Vergleich zu inline-size und normal

Die Wahl des richtigen container-type-Werts hängt vom tatsächlichen Anwendungsfall ab, nicht von einer pauschalen Vorliebe für die mächtigste Option.

In der Praxis deckt inline-size die überwiegende Mehrheit aller responsiven Komponenten ab, weil Breite die dominante Layout-Dimension in modernen, vertikal scrollenden Websites ist. container-type: size bleibt ein spezialisiertes Werkzeug für Fälle, in denen die Höhe eines Containers tatsächlich variabel und für die interne Darstellung relevant ist, mit der klaren Voraussetzung, dass diese Höhe explizit definiert werden muss, um den Kollaps-Bug zu vermeiden.

10. Zusammenfassung

container-type: size erweitert Container Queries um die Blockrichtung und erlaubt Abfragen nach Breite und Höhe gleichzeitig, erzwingt dafür aber Größen-Containment auf beiden Achsen. Ohne explizite Höhenquelle, sei es über feste Maße, aspect-ratio oder eine vorgegebene Grid-Zeile, kollabiert der Container auf null Pixel Höhe. Block-Size Queries sind seltener nötig als reine Breiten-Abfragen, in Video-Overlays und Dashboard-Widgets aber unverzichtbar.

Die Kombination mit aspect-ratio liefert vorhersagbare Höhen ohne manuelle Breakpoint-Pflege, während Style Queries zusätzliche, zustandsbasierte Logik unabhängig von der Größe ermöglichen. Performance-seitig bleibt container-type: size ein spezialisiertes Werkzeug, das gezielt dort eingesetzt werden sollte, wo Höhen-Abfragen einen echten Mehrwert liefern, während der Großteil responsiver Komponenten weiterhin mit inline-size auskommt.

11. FAQ: container-type: size Queries im Detail