Container-Queries in CSS – ein Ausblick

Am 11. Februar 2021 war es soweit: die CSS-Working-Group hat in einem Meeting das Thema Container-Queries mit »RESOLVED: Define container queries […]« beendet. Damit ist beschlossen, dass Container-Queries in der CSS-Spezifikation CSS Containment Module Level 3 spezifiziert werden. 🎉

Falls ihr euch jetzt fragt, »Was sind Container-Queries und warum freut sich Florian so darüber?«, findet ihr die Antwort in diesem Beitrag.

Was sind Container-Queries?

Über die Möglichkeit sogenannter Container-Queries wird schon länger diskutiert und sie sind ein großer Wunsch vieler Frontend-Entwickler:innen.

Zur Erklärung vielleicht erst einen Schritt zurück: mit Responsive Webdesign ging die Einführung der Media-Queries einher, mit denen CSS abhängig von Eigenschaften des Viewports (der Bereich des Browsers, in dem die Website dargestellt wird) ausgeführt werden kann. Am gängisten dürfte dabei der Fall sein, dass CSS nur ausgeführt wird, wenn der Viewport mindestens oder maximal eine bestimmte Breite hat. So können etwa hinter Burger-Icons versteckte Menüs zum immer sichtbaren Zustand auf größeren Viewports wechseln und mehrspaltige Layouts aktiv werden.

Dabei gibt es allerdings das Problem, dass sich Media-Queries immer auf den Viewport beziehen. Die Größe von Website-Elementen kann bisher mit CSS nicht als Entscheidungsgrundlage genutzt werden. Und hier kommen Container-Queries ins Spiel.

Schauen wir uns das anhand eines einfachen Beispiels an:

• Das Layout einer Website besteht aus einem Header, einem Inhaltsbereich und einem auf großen Viewports mehrspaltigen Footer mit Widget-Bereichen.
• Über das eingesetzte CMS kann ein User Galerien sowohl in den Inhaltsbereich als auch in den Footer einfügen und die Spaltenanzahl festlegen.
• Aktuell muss die Person, die das Design umsetzt, die Spalten-Darstellung der Galerien im Footer mit extra CSS anpassen, da eine Galerie mit vier Spalten auf großen Viewports im Inhaltsbereich gut aussieht, in einer Footer-Spalte allerdings viel zu klein ist. Für Galerien im Footer könnte das Styling also so überschrieben werden, dass Galerien maximal zwei Spalten haben.
• Wenn Container-Queries existieren, kann das Styling der Galerie so definiert werden, dass sich die Anzahl der Spalten nach der Breite des umschließenden Containers richtet, nicht nach der Breite des Viewports. In unserem Fall also beispielsweise nach der Breite des Inhaltsbereichs beziehungsweise der Footer-Spalte, die eine Galerie enthält. 🤯

Container-Queries erlauben also das Styling von Komponenten in Abhängigkeit zu einem übergeordneten Element. Damit wird es möglich sein, responsive Komponenten in unterschiedlichen Kontexten darzustellen, ohne sich um eine gequetschte oder gestreckte Darstellung sorgen zu müssen.

Natürlich müssen es keine ganzen Module wie Galerien sein, vorstellbar ist beispielsweise auch die Anpassung von Schriftgrößen oder -schnitten, um etwa eine Narrow-Version von einer Schrift bei wenig Platz einzusetzen oder bei Variable Fonts die Schriftparameter an den vorhandenen Platz anzupassen.

Wie könnten Container-Queries aussehen?

Der Vorschlag von Miriam Suzanne, der während des Meetings diskutiert wurde, baut auf dem Ansatz von David Baron mit der @container-Regel auf, womit eine Container-Querie wie folgt aussehen könnte:

@container (width > 30em) {
  .blocks-gallery-item {
    width: calc(50% - 0.5em);
  }
}Code-Sprache: CSS (css)

So würden Galerie-Elemente nur noch etwas weniger als 50 Prozent des Platzes einnehmen, wenn die Breite des Containers, auf den sich die @container-Regel bezieht, größer als 30em ist. Dieses Referenz-Element ist das nächstgelegene Elternelement mit einem Containment-Context, erzeugt durch die CSS-Eigenschaft contain. Wer, wie ich, bisher wenig über contain wusste: Im Smashing-Magazine-Artikel »Helping Browsers Optimize With The CSS Contain Property« erklärt Rachel Andrew, was es damit auf sich hat.

Im Fall des kleinen Beispiel-Codes oben könnten wir direkt für das blocks-gallery-grid-Element diesen Containment-Context erstellen, auf den sich dann die Container-Querie der Galerie-Elemente bezieht:

.blocks-gallery-grid {
  contain: layout inline-size;
}Code-Sprache: CSS (css)

Der Wert inline-size existiert bisher nicht, der ist aus dem Vorschlag von Miriam. Das Problem mit dem bereits vorhandenen Wert size ist, dass dafür neben der Breite auch die Höhe des Elements bekannt sein muss, was meist wegen flexibler Länge der Inhalte nicht gegeben ist. inline-size würde den Containment-Context dann nur auf die Inline-Achse beschränken, während ein potenzielles block-size den Containment-Context auf die Block-Achse beschränken könnte.

Falls keine übergeordneten Elemente mit Containment-Context vorhanden sind, sollte es nach dem Vorschlag einen Initial Containing Block geben, gegen den die Queries dann ausgeführt werden.

Das Prinzip erinnert an die position-Eigenschaft, wo beispielsweise ein Element mit position: absolute als Referenzpunkt zur Positionierung das nächste Elternelement mit position: relative oder einer gleichwertigen Eigenschaft-Wert-Kombination nutzt, etwa contain: layout.

Wann kommen Container-Queries?

Das wird leider noch dauern. Der aktuelle Stand bedeutet, dass ein möglicher Weg zur Umsetzung vorhanden ist, aber bis die Spezifikation (die eingangs erwähnte CSS Containment Module Level 3) fertig und von den Browsern implementiert ist, wird noch einige Zeit vergehen. Aber die Umsetzung ist nicht mehr utopisch, sondern eine Frage der Zeit. 🎉

Oder wie Amelia Bellamy-Royds auf Twitter schreibt:

It means browser teams & CSS spec editors have identified a possible path forward. There is still a long road to travel to get a final syntax specified & implemented, but that’s a lot better than the „aaaahhh, too many infinite loops, abort, abort“ reaction from a few years ago.

Amelia Bellamy-Royds auf Twitter