Zwei Jahre und ein paar Monate sind in der Lebensspanne eines CSS-Features eine kurze Zeit. Trotzdem reicht der Abstand, um nüchtern zu bilanzieren: Container Queries — seit Februar 2023 in Chrome 105+, Firefox 110+ und Safari 16+ Baseline — haben das Frontend-Layout in einer Weise umgekrempelt, die im Alltag spürbar ist, ohne dass viele Teams den Wendepunkt überhaupt bewusst datieren könnten. Die Anti-Pattern, gegen die wir 2021 noch argumentiert haben, sind in den Codebases von 2026 still ausgestorben. An ihre Stelle ist eine andere Art zu denken getreten — und sie hat Konsequenzen, die weit über @container hinausreichen.

Schauen wir hin.

Was Container Queries technisch sind

Zur Auffrischung, knapp. Eine Komponente erklärt sich selbst zum Query-Container und ermöglicht ihren Kindelementen, gegen die Maße dieses Containers zu reagieren — nicht gegen den Viewport.

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

@container card (min-width: 32rem) {
  .card__title {
    font-size: 1.5rem;
  }
  .card__layout {
    display: grid;
    grid-template-columns: 12rem 1fr;
  }
}

Zwei Properties (container-type, container-name) und ein neuer At-Rule-Block. Das ist die ganze Syntax. Was sie tut, ist nicht neu — das hat man jahrelang mit ResizeObserver und JavaScript-Klassen-Toggle nachgebaut — aber sie tut es deklarativ, ohne Layout-Thrashing, ohne Hydration-Cost.

inline-size ist der praktische Default; er beobachtet nur die horizontale Achse und vermeidet damit die zirkulären Layout-Probleme, die size (beide Achsen) im Wrapper-Setup erzeugen kann. In gut 95 % aller Realwelt-Fälle ist inline-size die richtige Wahl.

Komponentenorientiertes Layout — und das Ende einer Anti-Pattern

Das eigentlich Bemerkenswerte sind nicht die Queries selbst. Es ist, was sie unsichtbar gemacht haben.

Bis 2023 enthielt jede halbwegs ernsthafte Komponenten-Bibliothek — Material UI, Chakra, Ant Design, jedes Headless-System mit Layout-Anspruch — Variantenflags wie size="sm" | "md" | "lg" und Boolean-Props wie compact oder stacked. Diese Props waren keine Designentscheidung, sie waren ein Workaround. Sie kompensierten die Tatsache, dass eine Komponente nicht wissen konnte, wie viel Platz sie hat, ohne dass der Aufrufer ihr das explizit beibrachte.

Was 2026 in modernen Komponenten-Bibliotheken (Radix 4, shadcn/ui 2.x, headless-ui 2.x) auffällt: Diese Props verschwinden. Nicht alle auf einmal, nicht aus jeder Komponente, aber das Muster ist eindeutig. Eine Card, die in einem schmalen Sidebar-Container landet, weiß selbst, dass sie ihre Metadaten unter den Titel statt daneben packen muss. Sie braucht kein size="sm" mehr.

Container Queries haben den Style-Guide-Eintrag „prop-driven sizing” überflüssig gemacht. Komponenten regeln das jetzt selbst.

Damit verschwindet auch eine Anti-Pattern, die jahrelang im DACH-Frontend-Diskurs als „naja, geht halt nicht anders” verteidigt wurde: die Media Query, die auf die Viewport-Breite reagiert, um eine Komponente umzustellen. Was eine Komponente bei einer Viewport-Breite von 768 px tun soll, hängt nicht von der Viewport-Breite ab. Es hängt davon ab, wie viel Platz die Komponente in ihrem Layout-Kontext hat. Eine 320 px breite Card in einem dreispaltigen Desktop-Layout ist nicht „Desktop”. Sie ist eng. Die Media Query hat das nie gesehen; die Container Query sieht es.

Neue Design-Token-Konventionen

Eine subtilere Verschiebung betrifft Design-Tokens. Vor Container Queries hatten Token-Systeme typischerweise einen globalen breakpoint-Namespace: --bp-sm, --bp-md, --bp-lg, gemessen an Viewport-Breiten. Dieser Namespace existiert in vielen Codebases noch, aber er hat Konkurrenz bekommen.

Die neue Konvention — am deutlichsten in Token Studio 4 und in den 2025er-Updates der Adobe Spectrum-Tokens sichtbar — definiert Breakpoints pro Komponente:

.card {
  container-type: inline-size;
  --card-bp-sm: 18rem;
  --card-bp-md: 28rem;
  --card-bp-lg: 42rem;
}

@container (min-width: 28rem) {
  .card__media { aspect-ratio: 16 / 9; }
}

Das wirkt im ersten Moment redundant — warum nicht einfach 28rem direkt? — aber im laufenden Betrieb zahlt es sich aus. Die Breakpoints einer Card hängen nicht von der globalen Layout-Skala ab. Sie hängen davon ab, ab welcher Breite das Bild im Layout sinnvoll wird und ab welcher der Untertitel neben den Titel passt. Diese Schwellen sind komponenten­intrinsisch und gehören dorthin. Tailwind 4 hat diesen Gedanken in seine @container-Utilities übernommen: @sm:, @md:, @lg: als Container-Variants neben den klassischen sm:, md:, lg:.

Container Query Units — Fluid Typography ohne Tricks

Die zweite Spec-Ergänzung neben den Queries selbst sind die Container Query Units: cqw, cqh, cqi, cqb, cqmin, cqmax. Sie funktionieren wie vw/vh, beziehen sich aber auf den nächsten Query-Container statt auf den Viewport.

Für Typography Scaling sind sie der Game Changer, den vw nie ganz werden konnte. Eine Headline, die in einem Hero-Bereich groß und in einem Sidebar-Teaser klein sein soll, lässt sich heute deklarativ ausdrücken:

.teaser {
  container-type: inline-size;
}

.teaser__title {
  font-size: clamp(1.25rem, 6cqi, 2.5rem);
}

6cqi heißt: 6 % der Inline-Größe des Containers. In einem 320 px breiten Sidebar-Teaser ergibt das 19,2 px — also clamped auf den Floor von 1.25rem (20 px). In einem 800 px breiten Hero ergibt es 48 px — clamped auf den Ceiling von 2.5rem (40 px). Dazwischen interpoliert es linear. Kein JavaScript, kein ResizeObserver, kein Polyfill.

Was diese eine Zeile ersetzt, ist ein Stück Code, das in vielen Codebases zwischen 20 und 80 Zeilen lang war.

Drei Pattern, die heute Routine sein sollten

1. Card mit eigenem Breakpoint

.product-card {
  container-type: inline-size;
  display: grid;
  gap: 0.75rem;
}

@container (min-width: 24rem) {
  .product-card {
    grid-template-columns: 8rem 1fr;
    align-items: start;
  }
  .product-card__image { aspect-ratio: 1; }
}

@container (min-width: 40rem) {
  .product-card {
    grid-template-columns: 12rem 1fr auto;
  }
  .product-card__cta { justify-self: end; }
}

Die Card weiß selbst, ab welcher Breite sie horizontal aufklappt und ab welcher sie den CTA-Button rechts neben den Content stellt. Sie steht in Listen, Sidebars, Grids — überall reagiert sie richtig, ohne dass der Aufrufer eine Prop setzen muss.

2. Layout-Switching im Sidebar-Container

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

.widget {
  display: flex;
  flex-direction: column;
}

@container sidebar (min-width: 18rem) {
  .widget {
    flex-direction: row;
    align-items: center;
    gap: 1rem;
  }
}

Klassischer Fall: derselbe Widget-Bauplan in einer schmalen rechten Sidebar (Spalten-Layout) und in einem breiten Footer (Reihen-Layout). Container Query erledigt das, die Widget-Komponente kennt ihren Kontext nicht und muss ihn nicht kennen.

3. Fluid Typography via cqi

article {
  container-type: inline-size;
}

article h1 { font-size: clamp(1.75rem, 7cqi, 3.5rem); }
article h2 { font-size: clamp(1.25rem, 4.5cqi, 2.25rem); }
article p  { font-size: clamp(1rem, 1.8cqi, 1.125rem); }

Ein Magazin-Artikel, der in einer 70 ch breiten Lesespalte anders skaliert als in einer Print-Vorschau auf 120 ch — ohne Media Queries, ohne JS.

Style Queries — der nächste Schritt

Container Queries sind seit 2023 stabil. Container Style Queries sind das, was 2026 unterwegs ist. Die Syntax:

.panel {
  container-name: panel;
}

@container panel style(--variant: hero) {
  .panel__title {
    font-size: 3rem;
    letter-spacing: -0.02em;
  }
}

Hier reagiert das CSS nicht auf die Maße, sondern auf den Wert einer Custom Property im Container. Setzt der Container --variant: hero, greifen andere Regeln, als wenn er --variant: card setzt. Das ersetzt einen großen Teil dessen, was heute mit Daten-Attributen und [data-variant="hero"]-Selektoren gelöst wird — und es macht den Code besser komponierbar, weil Custom Properties durch den DOM-Baum vererbt werden.

Stand Mai 2026: Style Queries sind in Chromium 125+ und Safari 18 stabil verfügbar. Firefox liefert sie unter layout.css.container-style-queries.enabled aus; die Auslieferung als Default-on ist für Firefox 138 (Juli 2026) angekündigt. Damit wird Style Queries voraussichtlich im dritten Quartal 2026 Baseline. Wer heute beginnt, sie einzusetzen, sollte einen sauberen Fallback haben — was meistens trivial ist, weil die Regeln im Style-Query-Block einfach nicht greifen, wenn der Browser sie nicht kennt.

Was bleibt

Die Lehre aus zwei Jahren Container Queries ist nicht „CSS hat eine neue At-Rule bekommen”. Die Lehre ist, dass komponenten­orientiertes Layout ohne dieses Werkzeug nie wirklich konsequent möglich war. Wir haben es mit JavaScript nachgebaut, mit Resize-Observers, mit Props, mit Klassen-Toggles — und jede dieser Lösungen war ein Kompromiss. Container Queries machen den Kompromiss überflüssig, und das verändert, wie Bibliotheken geschrieben werden, wie Design-Tokens organisiert werden, wie wir über Skalierung nachdenken.

Wenn die Codebase, an der ihr arbeitet, noch immer Media Queries für Komponenten-Layout verwendet — und das Layout nicht ein bewusst viewport-getriebenes ist — dann arbeitet ihr 2026 mit Theorie von vorgestern. Investiert die zwei Sprints. Der Code danach ist nicht nur kürzer; er ist robuster gegen genau die Layout-Permutationen, die in jedem Refactor neu auftauchen.

Und der nächste Schritt steht schon vor der Tür. Style Queries werden in wenigen Monaten Baseline. Wer Container Queries verstanden hat, hat ein halbes Jahr Vorsprung.