Responsive Oberflächen mit Container Queries
Eine wiederverwendbare Wartungskarte entwickeln und bei unterschiedlichen Einbauorten, Grenzwerten und Texteinstellungen tatsächlich prüfen.
Container Queries passen eine Komponente an den tatsächlich verfügbaren Platz in ihrem umgebenden Container an. Eine Karte kann dadurch im breiten Inhaltsbereich anders aussehen als in einer schmalen Seitenleiste, obwohl beide auf demselben Bildschirm stehen. Für Größenabfragen bekommt ein Vorfahr einen passenden Containerkontext. Die bedingte Regel gestaltet anschließend Elemente innerhalb dieses Kontextes.
Der praktische Nutzen entsteht bei wiederverwendbaren Bausteinen. Dieser Beitrag entwickelt eine eigene fiktive Wartungskarte und prüft sie bei verschiedenen Containerbreiten. HTML, CSS und Prüffälle gehören zusammen. Die genannten Maße sind bewusst gewählte Entwurfswerte für dieses Beispiel und keine allgemeingültigen Gerätegrenzen. Ziel ist eine verlässliche Komponente, deren Inhalt auch ohne die zusätzliche Layoutverbesserung erreichbar bleibt.
Eine Komponente an verschiedenen Einbauorten verstehen
Stellen Sie sich eine Leistungsübersicht vor. Im Hauptbereich stehen ausführliche Karten, daneben gibt es eine schmale Sammlung passender Empfehlungen. Eine bisherige Media Query könnte bei breitem Browserfenster alle Karten nebeneinander anordnen. Für den Hauptbereich passt das möglicherweise. Die kleine Empfehlungskarte hat deshalb aber noch lange nicht genug Platz für dieselbe Aufteilung. Der Einbauort und die Bildschirmbreite beantworten unterschiedliche Fragen.
Eine an den verfügbaren Container gebundene Regel kann diese Unterscheidung ausdrücklich machen. Im Beispiel bleibt eine Karte untereinander aufgebaut, solange ihr eigener Einbaubereich schmal ist. Erst ab einer passenden Containerbreite wechseln Bildsymbol und Text in zwei Spalten. Das Browserfenster kann dabei unverändert bleiben. Die Karte muss nicht wissen, ob sie als Empfehlung, Suchergebnis oder Teil einer Leistungsübersicht eingesetzt wird.
Das bedeutet nicht, dass jede Media Query ersetzt werden sollte. Eine seitenglobale Navigation, eine übergreifende Inhaltsaufteilung oder eine Reaktion auf bestimmte Ausgabebedingungen kann weiterhin eine andere Grundlage benötigen. Entscheidend ist die Zuständigkeit: Soll die gesamte Seite reagieren oder ein Baustein auf seinen Platz? Wenn diese Frage geklärt ist, wird die Wahl der Regel verständlicher als durch eine pauschale Vorliebe für die neuere Syntax.
Container und gestaltetes Element bewusst trennen
Für unser Beispiel erhält eine äußere Hülle die Klasse service-slot. Darin liegt die eigentliche Karte. Diese Trennung macht deutlich, dass die Hülle den verfügbaren Raum bereitstellt und die Karte ihre Darstellung daran ausrichtet. Der Größenkontext wird mit container-type eingerichtet. Die Kurzform container kann zusätzlich einen Namen angeben. Ein sprechender Name erleichtert später die Zuordnung in umfangreicheren Stylesheets.
Die Größenabfrage richtet sich auf einen geeigneten Vorfahren des zu gestaltenden Elements. Wer nur die Karte selbst zum Container erklärt und in der Abfrage genau diese Karte verändern möchte, beschreibt deshalb nicht den vorgesehenen Zusammenhang. Eine zusätzliche Hülle ist häufig die einfachste Lösung. Sie erhält ihren Platz vom übergeordneten Layout, während die innere Komponente auf diesen Platz reagieren darf.
Die zusätzliche Hülle braucht keinen künstlichen semantischen Zweck. Sie kann ein gewöhnliches div bleiben. Die inhaltliche Bedeutung liegt bei der passenden Überschrift, dem Text und dem Link in der Karte. Eine rein gestalterische Containerklasse sollte nicht zu einem unnötigen Landmark oder zu einer weiteren Überschriftenebene führen. Die visuelle Wiederverwendung und die verständliche Dokumentstruktur müssen gemeinsam funktionieren.
Mit einem vollständigen eigenen HTML-Baustein beginnen
Das folgende HTML verwendet einen bewusst überschaubaren Inhalt. Die Zahl im roten Feld ist ein dekoratives Zeichen und wird für assistive Ausgabe ausgeblendet. Sie trägt keine Information, die im Text fehlen würde. Die Überschriftenebene muss in der späteren Seite zum umgebenden Inhalt passen. Im Beispiel steht die Karte innerhalb eines bereits gegliederten Bereichs und verwendet deshalb eine dritte Ebene.
<div class="service-slot">
<article class="service-card">
<div class="service-card__visual" aria-hidden="true">01</div>
<div class="service-card__content">
<h3>Wartung einer Webanwendung</h3>
<p>Umfang, Zuständigkeit und nächsten Prüftermin gemeinsam klären.</p>
<a href="/kontakt">Wartung besprechen</a>
</div>
</article>
</div>Die Inhaltsreihenfolge bleibt in beiden Layouts gleich: Zeichen, Überschrift, Erklärung und Link. Es gibt keine zweite mobile Fassung mit abweichenden Texten. Diese Entscheidung vereinfacht die Pflege und verhindert widersprüchliche Aussagen zwischen Einbauorten. Eine andere visuelle Spaltenzahl verändert in diesem Beispiel weder den Linkzweck noch die Reihenfolge der eigentlichen Information. Der Kontaktweg ist lediglich ein Beispieldestination innerhalb des vorhandenen Auftritts.
Die Grunddarstellung vor der bedingten Verbesserung gestalten
Die Grundregel bildet eine einspaltige Karte. Sie benötigt keine erfolgreiche Containerabfrage, um lesbar und bedienbar zu sein. Ab einer Containerbreite von 30 rem kommen zwei Spalten zum Einsatz. Die erste Spalte erhält sechs rem für das dekorative Zeichen. Die zweite darf sich mit minmax(0, 1fr) auf den verbleibenden Platz einstellen. Diese konkrete Aufteilung wird anschließend mit echten Inhalten geprüft.
.service-slot {
container: service-card / inline-size;
min-width: 0;
}
.service-card {
box-sizing: border-box;
display: grid;
grid-template-columns: minmax(0, 1fr);
gap: 1rem;
padding: 1.25rem;
border: 1px solid #c9c1b9;
background: #fff9ef;
color: #242a2e;
}
.service-card__visual {
display: grid;
place-items: center;
width: 4rem;
aspect-ratio: 1;
background: #bf0000;
color: #ffffff;
font: 700 1.5rem/1 sans-serif;
}
.service-card__content { min-width: 0; }
.service-card h3 { margin: 0 0 .5rem; overflow-wrap: anywhere; }
.service-card p { margin: 0 0 1rem; }
.service-card a { color: #a90000; text-underline-offset: .2em; }
.service-card a:focus-visible { outline: 3px solid #bf0000; outline-offset: 4px; }
@container service-card (min-width: 30rem) {
.service-card {
grid-template-columns: 6rem minmax(0, 1fr);
align-items: start;
}
.service-card__visual { width: 100%; }
}Die optischen Farben und Abstände dienen hier nur der nachvollziehbaren Darstellung des Beispiels. In einem bestehenden Gestaltungssystem würden passende vorhandene Rollen und Variablen verwendet. Für eine fachliche Erweiterung soll kein zweites konkurrierendes Farbsystem entstehen. Wichtig für das Verhalten sind der definierte Container, die einspaltige Basis und die räumlich begrenzte zusätzliche Regel. Diese Teile sollten beim Übertragen erkennbar erhalten bleiben.
Die Abfrage verwendet eine Mindestbreite und schließt den Grenzwert ein. Unter den gewählten Bedingungen mit einer Grundschrift von 16 Pixeln entsprechen 30 rem 480 Pixeln. Die Karte mit 479 Pixeln Containerbreite bleibt einspaltig. Bei 480 Pixeln greift die Erweiterung. Diese Zahlen beschreiben die konkrete Prüfumgebung. Für die spätere Verwendung gehören veränderte Schrifteinstellungen und weitere Einbauorte in die Kontrolle.
Den Umschaltpunkt aus dem Inhalt ableiten
Beginnen Sie die Gestaltung in einer schmalen Hülle und vergrößern Sie diese langsam. Beobachten Sie, ab wann zwei Spalten tatsächlich einen Vorteil bringen. Ein verkürzter Text kann früher nebeneinander passen als eine längere Übersetzung. Eine breite dekorative Fläche kann Platz beanspruchen, ohne die Besucheraufgabe zu unterstützen. Der Umschaltpunkt sollte deshalb aus der gewünschten Funktion entstehen und nicht aus einer übernommenen Liste bekannter Telefonbreiten.
Für unsere Karte sind mehrere Dinge gleichzeitig wichtig: Die Überschrift soll vollständig lesbar sein, der Erklärungstext darf nicht zu einer unruhigen schmalen Spalte werden und der Link braucht eine erkennbare Beziehung zur Beschreibung. Eine Messung der Spaltenzahl allein kann diese Fragen nicht beantworten. Sie bestätigt nur, dass die Regel ausgelöst wurde. Die Beurteilung des tatsächlichen Inhalts bleibt eine zusätzliche Aufgabe.
Halten Sie die Entscheidung knapp fest. Beispielsweise: Zwei Spalten werden verwendet, wenn nach dem dekorativen Zeichen noch ausreichend Raum für die getestete Überschrift und ihren Text bleibt. Diese Begründung hilft bei späteren Änderungen. Wird das Zeichen deutlich größer oder der Textumfang erweitert, ist sofort erkennbar, welche ursprüngliche Annahme erneut geprüft werden muss. Der Zahlenwert erhält damit einen nachvollziehbaren Zweck.
Die Größenwirkung der Containerfestlegung verstehen
Ein Größenkontext beeinflusst, wie der Browser Abhängigkeiten bei der Größenberechnung behandeln kann. Für den hier betrachteten horizontalen Aufbau wird inline-size verwendet. Die Breite der Hülle soll vom äußeren Layout festgelegt werden und nicht durch die Breite ihrer wechselnden Nachfahren entstehen. Sonst wäre eine Abfrage, die wiederum deren Darstellung ändert, schwer sinnvoll zu beurteilen. Die Trennung ist Teil der Konstruktion.
Verwenden Sie die umfassendere Festlegung size nicht lediglich aus Gewohnheit. Sie betrifft beide Größenrichtungen und kann zusätzliche Vorgaben erforderlich machen. Eine Hülle, deren Höhe bisher ausschließlich aus ihrem Inhalt entsteht, braucht eine andere Betrachtung als ein bewusst festgelegter Ausschnitt. Für eine gewöhnliche Textkarte genügt häufig die Abhängigkeit von der verfügbaren Breite. Die zusätzliche Möglichkeit ist kein Grund, unnötige Begrenzungen einzuführen.
Wenn eine Komponente nach der Umstellung unerwartet klein wird, untersuchen Sie zuerst die äußere Platzzuweisung. Ist die Hülle ein schmaler Flexeintrag? Wird ihre Breite durch ein anderes Raster begrenzt? Hat ein übergeordneter Bereich eine unerwartete Mindestgröße? Die sichtbare Karte ist nicht automatisch die Ursache. Eine Größenabfrage macht vorhandene Layoutbeziehungen häufig deutlicher und kann dadurch zuvor verdeckte Annahmen sichtbar machen.
Benannte und verschachtelte Container kontrollieren
Der Name service-card grenzt unseren Größenkontext fachlich ein. Im späteren Auftritt kann es zusätzlich einen Container für eine ganze Ergebnisliste geben. Eine Karte sollte dann bewusst auf die für sie gedachte Hülle reagieren. Ein sprechender Name und eine klar dokumentierte Position vermeiden, dass eine nachträglich eingefügte Zwischenhülle unbeabsichtigt die Grundlage einer unbenannten Abfrage verändert.
Eine Namensvergabe ist allerdings keine globale eindeutige Kennung wie eine HTML-ID. Mehrere Einbauorte können gleichnamige passende Container besitzen. Entscheidend bleibt der Zusammenhang im Vorfahrenbaum. Prüfen Sie bei verschachtelten Bausteinen, auf welche konkrete Hülle ein betroffenes Element reagieren kann. Zwei gleichlautende Namen ohne klare Zuständigkeit sind ebenso erklärungsbedürftig wie beliebige wechselnde Klassennamen.
Für eine Fehlersuche ist ein kleiner isolierter Fall hilfreich. Entfernen Sie zunächst zusätzliche Verschachtelungen und prüfen Sie eine einzelne Hülle mit fester Testbreite. Funktioniert die Regel dort, ergänzen Sie die realen äußeren Bereiche schrittweise. So lässt sich unterscheiden, ob die Syntax falsch ist oder eine andere Hülle ausgewählt wird. Ein weiteres zufälliges Media-Query-Override verdeckt das eigentliche Problem häufig nur.
Die Basis ohne Containerverbesserung erhalten
Eine brauchbare Grunddarstellung schützt die Besucheraufgabe, wenn die zusätzliche Regel nicht angewendet wird. In unserem Beispiel bleibt die Karte untereinander lesbar. Der Link ist weiterhin vorhanden und seine Beschriftung unverändert. Für die technische Prüfung kann die Containererweiterung bewusst entfernt werden. Das simuliert die Basiskonstruktion, ist aber kein Nachweis für das Verhalten jedes älteren Browsers. Diese Grenze gehört zum Prüfnachweis.
Prüfen Sie die tatsächlich benötigten Browser und Einbettungen gesondert. Eine vertraute Funktion kann in einer bestimmten älteren Webansicht fehlen oder anders unterstützt sein. Die aktuelle Dokumentation und ein geeigneter Zieltest sind dafür sinnvoller als eine pauschale Behauptung, dass Container Queries überall gleich funktionieren. Dieser Beitrag konzentriert sich auf Größenabfragen. Andere Abfragearten haben eigene Voraussetzungen und werden hier nicht als austauschbar behandelt.
Eine zusätzliche Abfrage mit @supports kann eine gestalterische Erweiterung ausdrücklich abgrenzen. Sie beweist jedoch nicht, dass der gesamte spätere Ablauf korrekt ist. Unterstützte Syntax und ein sinnvoller Inhalt sind verschiedene Prüfgegenstände. Wenn die einfache Basis die Aufgabe bereits erfüllt, muss nicht für jede Erweiterung eine zweite komplizierte Ersatzdarstellung gebaut werden. Überschaubare Zuständigkeiten erleichtern die langfristige Pflege.
Vergrößerung, Textlängen und Bedienung mitprüfen
Ein Wechsel in zwei Spalten darf Inhalte nicht abschneiden. Testen Sie lange Wörter, mehrzeilige Überschriften und eine ausführlichere Linkbeschriftung. Die Regel min-width: 0 und eine passende Umbruchregel können typische Mindestbreitenprobleme begrenzen. Sie ersetzen trotzdem keine Prüfung echter Inhalte. Eine Karte kann technisch innerhalb ihres Containers bleiben und ihren Text dennoch so unbequem umbrechen, dass die gewählte Aufteilung überarbeitet werden sollte.
Die Tastaturbedienung bleibt unabhängig von der Spaltenzahl erforderlich. Der Link muss erreichbar sein und sein Fokus darf nicht von einem übergeordneten Ausschnitt abgeschnitten werden. Die Reihenfolge im Dokument soll weiterhin zur Aufgabe passen. Für dieses Beispiel wird kein CSS-order verwendet. Unterschiedliche optische Positionen sollen nicht unbemerkt eine widersprüchliche Reihenfolge für andere Ausgabearten erzeugen.
Veränderte Texteinstellungen verdienen einen eigenen Test. Ein größerer Grundschriftwert kann den verfügbaren Platz und die Bewertung relativer Maße verändern. Prüfen Sie daher das konkrete Zusammenspiel statt einen bestimmten Pixelwert als dauerhaftes Versprechen zu behandeln. Insbesondere feste Höhen sind bei wechselnden Textmengen kritisch. Unsere Karte legt keine Höhe fest und kann mit ihrem Inhalt wachsen. Das ist eine bewusste Begrenzung des Beispiels.
Ein kleines prüfbares Testprotokoll anlegen
| Prüffall | Erwartung im Beispiel | Zusätzliche Beobachtung |
|---|---|---|
| Container 300 Pixel | Eine Spalte | Vollständiger Text und erreichbarer Link |
| Container 479 Pixel | Noch eine Spalte | Kein voreiliger Wechsel |
| Container 480 Pixel | Zwei Spalten bei 16-Pixel-Grundschrift | Grenzwert gehört zur Mindestbreite |
| Container 700 Pixel | Zwei Spalten | Sinnvolle Textbreite |
| Gleicher Viewport, zwei Einbauorte | Unterschiedliche Layouts möglich | Lokale Breite entscheidet |
| Containererweiterung entfernt | Lesbare einspaltige Basis | Inhalt und Link bleiben erhalten |
Die Tabelle trennt messbares Verhalten von gestalterischer Bewertung. Der Browser kann zuverlässig zeigen, ob eine oder zwei Spalten berechnet wurden. Für die Lesbarkeit muss der tatsächlich sichtbare Inhalt zusätzlich angesehen werden. Dokumentieren Sie bei einem Fehler möglichst den Einbauort, die Hüllenbreite, den Schriftstand und die betroffene Textfassung. Damit wird die Beobachtung später reproduzierbar, statt lediglich als unbestimmtes „mobil kaputt“ festgehalten zu werden.
Für die hier begleitende Grafik werden dieselben Inhalte bei unverändertem breitem Viewport in zwei unterschiedlich großen Hüllen dargestellt. Genau das macht den Unterschied zur alleinigen Bildschirmabfrage sichtbar. Die Abbildung soll keine vollständige Browserabdeckung behaupten. Ihr Wert liegt im kontrollierten Vergleich derselben Komponente unter zwei konkret benannten Platzbedingungen. Weitere Zielumgebungen erhalten eigene geeignete Prüffälle.
Containerbezogene Maße dosiert ergänzen
Neben der bedingten Aufteilung können containerbezogene Längeneinheiten eine Rolle spielen. Die Einheit cqi bezieht sich auf die Inlinegröße eines geeigneten Containers. Für einen horizontalen Beispielcontainer mit 300 Pixeln Breite entsprechen zwei cqi sechs Pixeln. Bei 700 Pixeln wären es 14 Pixel. Diese einfache Rechnung erklärt die Abhängigkeit. Sie sagt noch nicht, dass ein solcher Abstand für die Karte gestalterisch sinnvoll wäre.
Für fließende Werte braucht es deshalb oft eine untere und obere Grenze. Eine zusätzliche Beispielregel könnte den Abstand mit clamp(.75rem, 2cqi, 1.5rem) begrenzen. Bei 16 Pixeln Grundschrift läge die untere Grenze bei zwölf Pixeln und die obere bei 24 Pixeln. Das ist eine eigene Erweiterung und nicht die feste Abstandsvorgabe des oben gezeigten Hauptbeispiels. Ihre Wirkung sollte in einer getrennten Variante nachvollzogen werden.
Bei Verschachtelungen dürfen der benannte Abfragecontainer und die Grundlage einer Längeneinheit nicht ungeprüft gleichgesetzt werden. Die Einheit sucht einen für ihre Größenrichtung geeigneten Vorfahren. Eine zusätzliche innere Hülle kann deshalb eine andere Bezugsgröße schaffen als erwartet. Wenn ein fließender Abstand überraschend ausfällt, prüfen Sie die tatsächlich beteiligte Containerstruktur. Ein Name in einer anderen Regel macht die Herkunft eines Längenwertes nicht automatisch offensichtlich.
Im Hauptbeispiel bleibt der Abstand bewusst bei einem rem. Dadurch lässt sich der beobachtete Wechsel der Spalten auf die eigentliche Containerabfrage zurückführen. Für einen weiteren Versuch wird jeweils nur eine zusätzliche Entscheidung verändert und dokumentiert. Dieses Vorgehen vereinfacht die Auswertung: Eine unerwartete Textaufteilung kann gezielt mit einer neuen Spaltenbreite oder einem neuen Abstand in Verbindung gebracht werden, statt mehrere gleichzeitig geänderte Regeln auseinanderhalten zu müssen.
Die Umstellung einer vorhandenen Komponente begrenzen
In einem bestehenden Auftritt ist ein vollständiger Umbau aller Karten selten der beste erste Versuch. Wählen Sie einen Baustein mit klarer Aufgabe und zwei tatsächlich unterschiedlichen Einbauorten. Halten Sie dessen bisherigen Text, Linkzweck und grundlegende Bedienung fest. Ergänzen Sie dann die Hülle und die begrenzte Layoutregel. So lässt sich beurteilen, ob gerade die neue Abhängigkeit einen Vorteil bringt oder gleichzeitig veränderte Inhalte den Vergleich überlagern.
Prüfen Sie beim Übertragen außerdem vorhandene Selektoren. Eine alte Regel für die Seitenleiste könnte weiterhin zusätzliche Breiten setzen. Ein ehemaliger Media-Query-Override könnte die Containerregel später wieder überschreiben. Die Reihenfolge und Spezifität des gesamten Stylesheets bleiben relevant. Eine funktionierende neue Syntax hebt bestehende CSS-Regeln nicht auf. Entfernen Sie überflüssige Sonderfälle erst, wenn ihre frühere Aufgabe verstanden und die neue Variante tatsächlich geprüft ist.
Zum Abschluss braucht die Komponente eine kurze Gebrauchsbeschreibung für die Entwicklung. Darin stehen die erforderliche Hülle, ihr Name, die erwartete Platzzuweisung und die getesteten Grenzen. Das ist hilfreicher als eine Sammlung einzelner Bildschirmbilder ohne Zusammenhang. Wenn später ein weiterer Einbauort hinzukommt, kann die Entwicklung gezielt prüfen, ob er dieselben Voraussetzungen erfüllt. Die Wiederverwendung wird dadurch eine begründete technische Entscheidung und keine bloße Kopie sichtbarer Gestaltung.
Checkliste für wiederverwendbare Containerkomponenten
- Ist klar, weshalb der Baustein auf seinen Einbauplatz reagieren soll?
- Sind Containerhülle und gestaltetes Element sinnvoll getrennt?
- Erhält die Hülle ihren Platz nachvollziehbar vom äußeren Layout?
- Ist der Name bei verschachtelten Einbauorten eindeutig zuzuordnen?
- Funktioniert die Grunddarstellung ohne die zusätzliche Verbesserung?
- Ist der Umschaltpunkt durch echte Inhalte und ihre Aufgabe begründet?
- Wurden Werte knapp unter und genau auf der Grenze geprüft?
- Bleiben lange Texte, Tastaturfokus und veränderte Texteinstellungen nutzbar?
- Ist die tatsächliche Zielumgebung geprüft und der Nachweis passend begrenzt?
Quellen und fachlicher Stand
Quellenstand: 9. November 2026. Die folgenden Primärquellen erläutern Größenkontexte und Abfragesyntax. Der CSSWG-Text ist ein Arbeitsentwurf und wird entsprechend eingeordnet. Karte, Entwurfsentscheidung und kontrollierte Prüffälle dieses Beitrags sind eigene Ausarbeitungen.
