Über ein Jahrzehnt lang basierte responsives Webdesign auf einer einzigen Idee: Media Queries reagieren auf die Größe des Browserfensters. Das funktionierte – bis Komponenten ins Spiel kamen, die an völlig unterschiedlichen Stellen einer Seite landen. Container Queries drehen das Prinzip um: Statt auf das Fenster reagiert eine Komponente auf die Größe ihres eigenen Containers. Das ist eine der bedeutendsten CSS-Neuerungen der letzten Jahre, und in diesem Artikel erfährst du, warum.
Das Problem mit Media Queries
Stell dir eine Produktkarte vor: Bild, Titel, Preis, Button. In der breiten Sidebar soll sie kompakt und einspaltig erscheinen, im breiten Hauptbereich dagegen als Querformat mit Bild links und Text rechts. Mit klassischen Media Queries ist das kaum sauber lösbar, denn sie kennen nur die Fensterbreite – nicht den Platz, der der Karte tatsächlich zur Verfügung steht.
Das Ergebnis war jahrelang ein Wust aus Kontextklassen wie card--sidebar und card--main, oft kombiniert mit fragilen Breakpoints. Eine wirklich wiederverwendbare, kontextunabhängige Komponente war so nicht zu bauen. Genau hier setzen Container Queries an.
Wie Container Queries funktionieren
Das Prinzip ist in zwei Schritten erklärt. Zuerst erklärst du ein Element zum abfragbaren Container, dann formulierst du Regeln, die auf dessen Größe reagieren:
- Container definieren: Dem Eltern-Element gibst du
container-type: inline-size. Damit wird seine Inline-Größe (meist die Breite) zur Referenz für Abfragen. - Optional benennen: Mit
container-name: kartevergibst du einen Namen, um gezielt einen bestimmten Container abzufragen. - Abfrage schreiben: Mit
@container (min-width: 400px) { ... }definierst du Stile, die nur greifen, wenn der Container mindestens 400 Pixel breit ist.
Der entscheidende Unterschied zu Media Queries: Die Abfrage interessiert sich nicht für das Browserfenster, sondern ausschließlich für den nächstgelegenen passenden Container. Dieselbe Karte verhält sich in der Sidebar anders als im Hauptbereich – mit identischem CSS und ohne Kontextklassen.
container-type im Detail
Die Eigenschaft container-type kennt drei sinnvolle Werte, und die Wahl hat Konsequenzen:
- inline-size: Der häufigste Fall. Abgefragt wird nur die Inline-Achse (Breite im westlichen Schriftsystem). Die Höhe richtet sich frei nach dem Inhalt.
- size: Sowohl Breite als auch Höhe werden abfragbar. Achtung: Das erfordert, dass der Container eine eigene Größe hat, was schnell zu Layout-Problemen führt.
- normal: Kein Größen-Container, aber nutzbar für Style-Queries.
Wichtig zu wissen: Ein Element, das du zum Container machst, erzeugt einen neuen Containment-Kontext. In der Praxis fragst du fast nie das Element selbst ab, sondern stylst seine Kinder. Deshalb wickelt man die Komponente meist in einen schlanken Wrapper, der den container-type trägt.
Container-Units: cqw, cqi und Verwandte
Container Queries bringen ein eigenes Set an Einheiten mit, die sich auf die Containergröße beziehen – nicht auf den Viewport wie vw und vh:
- cqw: 1 % der Containerbreite.
- cqh: 1 % der Containerhöhe.
- cqi: 1 % der Inline-Größe (die robustere Variante von cqw).
- cqb: 1 % der Block-Größe.
- cqmin / cqmax: der jeweils kleinere oder größere der beiden Werte.
Damit lässt sich etwa eine Schriftgröße bauen, die mit dem Container skaliert: font-size: clamp(1rem, 5cqi, 2rem). Die Überschrift wächst und schrumpft elegant mit dem verfügbaren Platz – egal, wo die Komponente eingebettet ist. Solche flüssigen Größen ersetzen oft eine ganze Treppe von Breakpoints.
Praxisbeispiel: Eine wirklich wiederverwendbare Karte
So sieht ein typischer Aufbau aus: Ein Wrapper bekommt container-type: inline-size. Die Karte selbst ist standardmäßig einspaltig mit display: flex; flex-direction: column. Dann fügst du eine Abfrage hinzu: @container (min-width: 450px) { .karte { flex-direction: row } }. Sobald der Wrapper breit genug ist, kippt die Karte ins Querformat – ohne dass die Karte jemals weiß, ob sie in einer Sidebar, einem Grid oder einem Modal steckt.
Das ist der Heilige Gral des komponentenbasierten Designs: Du baust eine Komponente einmal, und sie passt sich überall korrekt an. Für Frameworks wie React, Vue oder Svelte ist das ein Quantensprung, weil Komponenten dort genau diese Kontextunabhängigkeit anstreben.
Style Queries: Der nächste Schritt
Neben Größenabfragen gibt es Style Queries, mit denen du auf die Werte von Custom Properties reagierst. Setzt eine Elternkomponente etwa --theme: dark, können Kinder mit @container style(--theme: dark) { ... } darauf reagieren. Das ist mächtig für Theming und Varianten, befindet sich aber noch in einer früheren Verbreitungsphase als die Größenabfragen. Wer tiefer in das Konzept dahinter einsteigen will, findet in unserem Beitrag zu CSS Custom Properties die Grundlagen.
Browser-Support und Fallbacks
Container Queries werden seit 2023 von allen großen Browser-Engines (Chromium, Firefox, Safari) unterstützt und gelten heute als produktionsreif. Den exakten Stand prüfst du am besten in einer Kompatibilitätsdatenbank – siehe unseren Artikel zu caniuse.
Für sehr alte Browser kannst du mit @supports (container-type: inline-size) einen sauberen Fallback bauen: Greift die Abfrage nicht, fällt die Komponente auf ein einfaches, einspaltiges Layout zurück. Das ist Progressive Enhancement im besten Sinne – moderne Browser bekommen das volle Erlebnis, ältere eine funktionierende Basisversion.
Fazit: Ein Paradigmenwechsel
Container Queries lösen Media Queries nicht ab, sie ergänzen sie. Für globale Layout-Entscheidungen (etwa Seitengerüst und Navigation) bleiben Media Queries sinnvoll. Für einzelne, wiederverwendbare Komponenten sind Container Queries klar überlegen, weil sie endlich vom Kontext entkoppeln. Wenn du in Komponenten denkst – und das tun heute praktisch alle modernen Frontend-Stacks – gehören Container Queries in dein Standardrepertoire. Probier sie an deiner nächsten Karte aus und du wirst nicht mehr zurückwollen.