Style Queries mit Container: fortgeschrittene Anwendungsfälle

1. Was Style Queries sind und wie sie sich von Size-basierten Container Queries unterscheiden

Container Queries wurden zuerst als reine Größenabfrage bekannt: @container (min-width: 400px) lässt eine Komponente auf den verfügbaren Platz ihres nächsten benannten Vorfahren reagieren, unabhängig von der Viewport-Breite. Style Queries erweitern dasselbe Grundprinzip um eine völlig andere Bedingungsart: Statt nach Abmessungen zu fragen, prüft @container style(...), ob eine bestimmte CSS Custom Property auf dem Container einen bestimmten Wert hat, und wendet Regeln nur dann an, wenn diese Bedingung erfüllt ist.

Der entscheidende Unterschied zu einer klassischen Klasse ist die Blickrichtung: Eine Klasse wird direkt auf das Element gesetzt, das sich ändern soll, während eine Style Query die Bedingung am Vorfahren prüft und die Kind-Elemente reagieren lässt, ganz ohne dass diese selbst eine Klasse tragen müssen. Das macht Style Queries besonders wertvoll für Design-System-Komponenten, deren innere Struktur nicht wissen soll, in welchem Theme oder Kontext sie gerade gerendert wird.

2. Die style()-Syntax: Custom Properties als Bedingung abfragen

Die Grundsyntax lautet @container style(--eigenschaft: wert) { ... } und prüft den berechneten Wert der angegebenen Custom Property auf dem nächsten Container, der über container-type als Query-Container definiert wurde. Anders als bei Size Queries braucht ein Style-Query-Container aktuell in den meisten Implementierungen keinen expliziten container-type: size, weil Style Queries unabhängig von einer Größenberechnung funktionieren.

Wichtig ist, dass die Bedingung exakt den berechneten String-Wert vergleicht, nicht etwa numerisch größer oder kleiner. Eine Custom Property mit dem Wert dark erfüllt nur eine Bedingung, die exakt nach dark fragt, nicht nach einem Bereich oder einem Teilstring. Das macht Style Queries syntaktisch einfacher als Size Queries, schränkt aber gleichzeitig ein, wie die Bedingungen formuliert werden können.

.card-container {
  --theme: light;
  container-name: card;
}

@container card style(--theme: dark) {
  .card {
    background-color: #18181b;
    color: #f4f4f5;
    border-color: #3f3f46;
  }
}

3. Anwendungsfall: Theme-Varianten über eine Custom Property am Elternelement steuern

Der naheliegendste Anwendungsfall für Style Queries ist Theming auf Komponentenebene: Eine Custom Property wie --theme wird einmal am äußeren Container gesetzt, etwa abhängig davon, in welchem Seitenbereich eine Karten-Komponente eingebettet ist, und jede Karte innerhalb dieses Containers reagiert automatisch, ohne dass die Karte selbst eine Theme-Klasse tragen oder eine JavaScript-Logik den Kontext weiterreichen muss.

Das ist besonders in Design-Systemen mit vielen wiederverwendeten Komponenten wertvoll, weil die Komponente selbst vollkommen kontextfrei bleibt: Dieselbe .card-Regel funktioniert identisch, egal ob sie in einem hellen Marketing-Bereich oder einem dunklen Dashboard-Bereich der Anwendung landet, solange der jeweilige Elternbereich die passende Custom Property setzt. Das entkoppelt die Komponentendefinition von der Stelle, an der sie tatsächlich verwendet wird.

/* Marketing area sets a light theme on its section container */
.marketing-section { --theme: light; container-name: theme-scope; }

/* Dashboard area sets a dark theme on its section container */
.dashboard-section { --theme: dark; container-name: theme-scope; }

/* The card component itself never needs a theme class */
@container theme-scope style(--theme: dark) {
  .card { background: #1f2937; color: #e5e7eb; }
}
@container theme-scope style(--theme: light) {
  .card { background: #ffffff; color: #111827; }
}

4. Anwendungsfall: Layout-Dichte (kompakt/komfortabel) ohne zusätzliche Klassen

Ein zweiter praktischer Anwendungsfall ist die Steuerung der Layout-Dichte, etwa in Tabellen oder Listen mit einem umschaltbaren Modus kompakt gegenüber komfortabel. Statt für jede Dichte-Variante eine eigene CSS-Klasse auf jedem betroffenen Kind-Element zu pflegen, genügt eine einzige Custom Property am gemeinsamen Container, und jede Zeile, jede Zelle und jeder Innenabstand reagiert konsistent auf denselben Wert.

Dieser Ansatz reduziert vor allem die Anzahl an Stellen, an denen Dichte-Logik dupliziert werden müsste. Statt zehn verschiedene Kind-Elemente jeweils einzeln mit .compact-Modifikator-Klassen zu versehen, wird die Dichte-Entscheidung an genau einer Stelle getroffen und über Style Queries an alle betroffenen Regeln weitergereicht, was Wartbarkeit und Konsistenz deutlich verbessert.

.data-table-wrapper {
  --density: comfortable;
  container-name: table-density;
}

@container table-density style(--density: compact) {
  td, th { padding-block: 0.25rem; font-size: 0.8125rem; }
  tr { line-height: 1.2; }
}

@container table-density style(--density: comfortable) {
  td, th { padding-block: 0.75rem; font-size: 0.875rem; }
  tr { line-height: 1.5; }
}

5. Boolean-artige Custom Properties und der Unterschied zu echten booleschen Werten in CSS

CSS kennt keinen eigenen booleschen Datentyp, weshalb Style Queries für scheinbar binäre Zustände meist mit String-Werten wie true/false oder einer expliziten Ein-Wert-Konvention arbeiten. Die Spezifikation erlaubt zwar eine Kurzform, die eine gesetzte, nicht-leere Custom Property als wahr behandelt, die Unterstützung dieser Kurzform ist zwischen den Browser-Engines aber noch uneinheitlicher als die Kernfunktion selbst.

In der Praxis ist es deshalb robuster, für boolesche Zustände immer einen expliziten String-Wert zu verwenden und die Bedingung eindeutig zu formulieren, etwa @container style(--collapsed: true) statt sich auf die reine Existenz der Property zu verlassen. Das macht den Code zwar minimal ausführlicher, verhält sich aber über verschiedene Browser-Versionen hinweg deutlich vorhersehbarer.

6. Style Queries mit Size Queries kombinieren

Style Queries und klassische Size Queries schließen sich nicht gegenseitig aus und lassen sich in einer einzigen @container-Regel kombinieren, indem die Größenbedingung und die style()-Bedingung durch and verbunden werden. Das erlaubt Regeln wie nur wenn der Container mindestens 500px breit ist und gleichzeitig das dunkle Theme aktiv ist, was mit reinen Media Queries oder reinen Klassen deutlich umständlicher zu formulieren wäre.

Diese Kombination ist besonders für responsive Design-Systeme wertvoll, die sowohl auf verfügbaren Platz als auch auf thematischen Kontext reagieren müssen, etwa eine Komponente, die im schmalen, dunklen Kontext ein reduziertes Layout zeigt, im breiten, dunklen Kontext aber ein erweitertes Layout mit zusätzlichen Metadaten. Eine einzige kombinierte Query deckt diesen Fall ab, ohne verschachtelte Media Queries oder zusätzliche JavaScript-Logik.

@container sidebar (min-width: 500px) and style(--theme: dark) {
  .widget {
    grid-template-columns: 1fr 1fr;
    background: #111827;
  }
}

7. Vererbung, Kaskade und warum Style Queries die Custom Property am Container selbst brauchen

Eine wichtige Einschränkung betrifft die Kaskade: Style Queries werten den berechneten Wert einer Custom Property auf dem Container-Element selbst aus, nicht auf dem abfragenden Kind-Element. Das bedeutet, dass eine Custom Property, die nur über Vererbung von einem noch weiter entfernten Vorfahren beim Container ankommt, in vielen Implementierungen zuverlässiger erkannt wird, wenn sie explizit auf dem als Query-Container definierten Element selbst gesetzt ist, statt sich ausschließlich auf implizite Vererbungsketten zu verlassen.

In der Praxis bedeutet das: Wer eine Custom Property irgendwo hoch oben im Dokumentbaum setzt und erwartet, dass jeder beliebige, weiter unten definierte Query-Container diese automatisch sieht, sollte das in jedem Zielbrowser testen. Der robustere Ansatz ist, die relevante Custom Property direkt auf dem Element zu setzen, das auch als benannter Query-Container fungiert, statt sich auf mehrstufige Vererbung zu verlassen.

8. Browser-Support-Realität und ein sicheres Fallback-Pattern

Style Queries sind eine der jüngeren Erweiterungen der Container-Query-Spezifikation, und der Browser-Support liegt spürbar hinter den reinen Size-basierten Container Queries zurück, die inzwischen breit verfügbar sind. Chromium-basierte Browser unterstützen style() für Custom-Property-Bedingungen am längsten, während andere Engines teilweise nur experimentell oder noch gar nicht unterstützen, weshalb der praktische Einsatz aktuell eine bewusste Progressive-Enhancement-Entscheidung ist.

Das sichere Fallback-Pattern setzt die Basisstile außerhalb jeder Style Query und lässt @container style(...) ausschließlich zusätzliche, nicht-kritische Anpassungen vornehmen. Ein Browser ohne Unterstützung ignoriert die gesamte Regel und zeigt die Basisstile, ein unterstützender Browser bekommt die verfeinerte Variante, aber kein Nutzer sieht jemals ein kaputtes oder unvollständiges Layout.

/* Base styles work everywhere, with or without style() support */
.card {
  background: #ffffff;
  color: #111827;
  border: 1px solid #e5e7eb;
}

/* Progressive enhancement: only refines the theme where supported */
@supports (container-type: inline-size) {
  @container theme-scope style(--theme: dark) {
    .card {
      background: #18181b;
      color: #f4f4f5;
      border-color: #3f3f46;
    }
  }
}

9. Wann Style Queries die richtige Wahl sind, wann Klassen weiterhin besser passen

Style Queries lohnen sich vor allem dort, wo eine Komponente kontextfrei bleiben soll und die Kontextinformation bereits als Custom Property vorliegt oder ohnehin gesetzt werden muss, etwa für Design Tokens. Für einfache, binäre Zustände, die sich problemlos über eine einzige zusätzliche Klasse auf dem betroffenen Element selbst ausdrücken lassen, bleibt eine klassische Klasse oft die pragmatischere und browserübergreifend zuverlässigere Wahl.

Die Entscheidung zwischen Style Query und Klasse ist letztlich eine Frage der Verantwortlichkeit: Style Queries eignen sich, wenn der Kontext von außen kommt und die Komponente selbst nichts über ihn wissen soll. Klassen eignen sich, wenn der Zustand direkt am betroffenen Element bekannt ist und keine zusätzliche Indirektion über einen Container nötig ist. Beide Techniken schließen sich nicht aus, sondern ergänzen sich je nach Architektur.

10. Zusammenfassung

11. FAQ: Container Style Queries: Das Wichtigste auf einen Blick