Dieselbe Teaser-Kachel steht auf vielen WordPress-Seiten an zwei Stellen: in der breiten Hauptspalte und in der schmalen Sidebar. Mit Media Queries bekommt sie an beiden Stellen dasselbe Layout, weil beide Stellen im selben Browserfenster liegen — in der Sidebar steht das Bild dann neben einem Titel, für den kaum Platz bleibt. Container Queries fragen stattdessen die Breite der Spalte ab, in der die Kachel tatsächlich steht. Dieser Beitrag zeigt den Aufbau an einem nachgebauten Fall: HTML, CSS, Browserstand, Prüfschritte für die Abnahme und die Stellen, an denen die Umstellung nichts bringt.

1. Der Fall, und was daran Demonstration ist

CSS Container Queries lösen ein konkretes Problem: Dieselbe Komponente soll sich je nach Spaltenbreite anders darstellen, nicht je nach Fensterbreite. Ein abgenommenes, öffentlich zeigbares Kundenprojekt liegt uns nicht vor. Der folgende Aufbau ist ausdrücklich eine Demonstration, die Sie Zeile für Zeile nachbauen können. Alle Breitenangaben stammen aus dem unten abgedruckten CSS. Aussagen über eingesparte Stunden oder geringere Kosten treffen wir nicht.

Der Aufbau: eine Inhaltsseite mit zwei Spalten. Die Hauptspalte nimmt den Rest der Breite, die Sidebar ist auf 320 Pixel festgelegt, dazwischen 48 Pixel Abstand, die Seite auf 1200 Pixel begrenzt. In beide Spalten kommt dieselbe Teaser-Kachel: Bild links, daneben Titel und Anriss.

Der Darstellungsfehler zeigt sich sofort. Das Bild belegt 140 Pixel plus 20 Pixel Abstand. In der Hauptspalte bleiben rund 670 Pixel für den Text, in der Sidebar etwa 140. Eine Spalte, in der Überschriften umbrechen und lange Wörter über den Rand laufen. Mit Media Queries ist das nicht sauber zu lösen, weil beide Kacheln dieselbe Fensterbreite sehen.

2. Fensterbreite und Containerbreite mit CSS Container Queries erklärt

Eine Media Query misst das Browserfenster. Steht das Fenster auf 1200 Pixel, gilt @media (min-width: 768px) für jedes Element, gleichgültig ob es in der 832 Pixel breiten Hauptspalte oder in der 320 Pixel breiten Sidebar steht.

Eine Container Query misst ein Elternelement. Laut MDN wird ein Element über container-type zum Abfrageziel, und die @container-Regel wendet Stile auf dessen Nachkommen an, sobald die Bedingung zutrifft. Ohne eigenen Container ist der Container die Seite selbst. web.dev beschreibt, dass 1cqi dann 1svi entspricht. Ohne Hüllelement messen Sie also wieder das Fenster.

3. Der Vergleich in Zahlen

Dieselbe Seite, drei Fensterbreiten. Die Werte folgen aus dem Layout-CSS in Abschnitt 4:

• Fenster 1280 px: Hauptspalte 832 px, Sidebar 320 px. Die Media Query liefert beidemal 1280. Die Container Query liefert 832 beziehungsweise 320.
• Fenster 1000 px: Hauptspalte 584 px, Sidebar 320 px. Die Media Query liefert beidemal 1000. Die Container Query liefert 584 beziehungsweise 320.
• Fenster 760 px: Layout gestapelt, beide Spalten 712 px. Beide Ansätze liefern dasselbe Ergebnis.

Der Nutzen entsteht nur dort, wo ein Baustein in unterschiedlich breiten Spalten vorkommt.

4. HTML und CSS der Kachel

Ein Hüllelement, darin die eigentliche Kachel:

<div class="kachel-huelle">

  <article class="kachel">

    <img class="kachel__bild" src="…" alt="…">

    <div class="kachel__text"><h3>…</h3><p>…</p></div>

  </article>

</div>

.inhalt { max-width: 1200px; display: grid; grid-template-columns: minmax(0, 1fr) 320px; gap: 48px; }

.kachel-huelle { container-type: inline-size; container-name: kachel; }

.kachel { display: grid; grid-template-columns: 1fr; gap: 12px; }

@container kachel (min-width: 420px) { .kachel { grid-template-columns: 140px 1fr; gap: 20px; align-items: start; } }

@container kachel (min-width: 420px) { .kachel h3 { font-size: clamp(1.05rem, 0.85rem + 1.1cqi, 1.5rem); } }

Warum das Hüllelement? Eine Container Query kann das abgefragte Element selbst nicht gestalten. LogRocket beschreibt den Grund: Ohne diese Trennung würde das Anwenden von Stilen die Größe des Containers neu berechnen und eine Endlosschleife erzeugen.

Warum inline-size? inline-size legt laut MDN nur in der Inline-Achse Containment fest; die Höhe wächst weiter mit dem Inhalt. size wendet Containment in beiden Richtungen an. Für eine Kachel, deren Höhe vom Text abhängt, führt das zu einer in sich zusammenfallenden Box.

5. Warum der Umschaltpunkt bei 420 Pixeln liegt

420 ist keine Gerätebreite. Bild und Abstand belegen 160 Pixel, die Textspalte braucht etwa 260 Pixel für lesbare Zeilen (rund 30–35 Zeichen bei 17 px). 160 plus 260 ergibt den Umschaltpunkt. Fällt die Entscheidung knapp aus, setzen Sie den Punkt lieber zehn Pixel höher: Eine gestapelte Kachel in einer etwas zu breiten Spalte sieht großzügig aus, eine zweispaltige in einer zu schmalen sieht kaputt aus.

Der Umschaltpunkt gehört zum Baustein, nicht zum Bildschirm. Er beantwortet die Frage: Ab welcher Breite trägt dieser Inhalt zwei Spalten?

6. Warum die Schriftgröße Grenzen braucht

clamp() setzt die Grenzen: Untergrenze, containerabhängiger Mittelwert, Obergrenze. Die Einheit cqi entspricht einem Prozent der Inline-Größe des Containers. Im Beispiel ergibt das bei 420 px rund 1,13 rem und bei 832 px rund 1,42 rem. Dieselbe Technik zeigt Ahmad Shadeed an einem Titel mit clamp(14px, 10px + 1.33cqw, 20px). Weil Unter- und Obergrenze in rem stehen, bleibt die Schrift an die Browser-Grundeinstellung gekoppelt.

7. Quellenkasten: Browser, Baseline, Einheiten

Alle Angaben geprüft am 8. Oktober 2026.

• Erste Auslieferung: Chrome 105 und Safari 16. OddBird vermerkt, dass Safari 16 am 12. September 2022 mit Größenabfragen erschien. Für Chrome 105 nennen CSS-Tricks den 30. August, der Features Explorer den 2. September 2022.
• Letzte große Engine: Firefox 110, 14. Februar 2023 (Features Explorer).
• Baseline-Status: „Newly available“ Februar 2023. Der Features Explorer führt Größenabfragen als „Widely Available (since 2025-08-14)“. Verbreitung: rund 23 % der Seitenaufrufe nach Chrome Platform Status.
• Einheiten: cqw, cqh, cqi, cqb, cqmin, cqmax, jeweils ein Prozent des Bezugsmaßes (Frontend Masters). Für Layouts in Leserichtung ist cqi der Normalfall.

8. Was Container Queries nicht können

Drei Grenzen sind relevant. Erstens misst ein Container sich nicht selbst, jedes Markup braucht eine Ebene mehr. Zweitens lässt sich in der Abfrage keine CSS-Variable verwenden; Smashing Magazine zeigt, dass @container (min-width: var(--breakpoint-lg)) nicht funktioniert. Drittens sind Stilabfragen eine eigene Baustelle: LogRocket ordnet ein, dass die vollständige Variante noch nicht breit unterstützt wird; ein Branchenbericht meldet Baseline-Status „Newly available“ für Custom Properties. Die Einschätzungen widersprechen sich. Behandeln Sie Stilabfragen als Zusatz, nicht als Fundament.

9. WordPress-Besonderheiten: Editor, Editor-Styles, Page Builder

Container Queries funktionieren im WordPress-Frontend wie auf jeder anderen Seite. Im Editor ist das anders: Seit WordPress 6.3 läuft er in einem Iframe (Dev-Note zu 6.3). Eine Dev-Note vom November 2025 beschreibt den weiteren Weg: Kompatibilitätsmaßnahmen in 6.9, vollständiger Umstieg für 7.0 geplant. In Issue 81364 heißt es, dass Media Queries außerhalb des Iframes gegen den Viewport der Administrationsoberfläche aufgelöst werden. Container Queries sind davon unabhängig, weil sie das Elternelement messen.

Gemeldet wurden Probleme beim Laden von Editor-Stilen: Issue 46277 beschreibt, dass eine @container-Regel in einer über add_editor_style eingebundenen Datei einen Fehler erzeugte. Issue 49862 meldet, dass ein Stylesheet mit Container Queries gar nicht geladen wurde. Ob beides behoben ist, geht aus den vorliegenden Quellen nicht hervor, prüfen Sie es auf Ihrer Installation. Zu WPBakery Page Builder liegt uns kein eigener Test vor; wir behaupten deshalb nichts über das Verhalten.

10. Ein Fall, in dem die Umstellung nichts brachte

Bei einer einspaltigen Landingpage brachte die Umstellung auf Container Queries keinen Unterschied. Die Containerbreite entsprach auf jeder Fenstergröße der Inhaltsbreite, der Umschaltpunkt feuerte also genau dann, wenn die alte Media Query gefeuert hätte. Die Voraussetzung für einen Nutzen: Ein Baustein muss in mindestens zwei unterschiedlich breiten Umgebungen vorkommen. Trifft das nicht zu, bleiben Media Queries die einfachere Lösung.

11. Briefing und Abnahme: was Sie verlangen sollten

1. Einbauorte benennen. Für jeden Baustein steht im Briefing, in welchen Spalten er vorkommt und wie breit diese sind.
2. Umschaltpunkte begründen lassen. Zu jedem Wert gehört ein Satz, der ihn aus dem Inhalt herleitet.
3. Test in drei Containerbreiten. Den Baustein in der schmalsten Spalte, knapp unterhalb und knapp oberhalb des Umschaltpunkts einbauen.
4. Test mit der längsten echten Überschrift. Geprüft wird auf Überlauf, Silbentrennung und Zeilenzahl in der schmalsten Spalte.
5. Editor und Frontend getrennt abnehmen. Dieselbe Seite in Editoransicht und veröffentlicht, beides mit Screenshot.
6. Browser und Prüfdatum protokollieren.

12. Fazit

Container Queries lohnen sich dort, wo derselbe Baustein in verschiedenen Spaltenbreiten steht. Bei Teaser-Kacheln, Produktboxen, Autorenkästen, Formularen in Sidebars. Überall sonst fügen sie Markup und Komplexität hinzu, ohne die Darstellung zu ändern.

Gehen Sie Ihre Bausteine durch und notieren Sie, in welchen Spaltenbreiten jeder vorkommt. Die mit mehr als einer Breite sind Ihre Kandidaten. Beginnen Sie mit einem einzigen, legen Sie die Testseite an, prüfen Sie Editor und Frontend getrennt. Erst wenn dieser Baustein über ein Theme-Update hinweg stabil geblieben ist, lohnt sich der zweite.