Subgrid und Masonry kombinieren: komplexe Rasterlayouts ausrichten

1. Das Problem: ungleiche Kartenhöhen und trotzdem ausgerichtete Inhalte

Ein Karten-Raster mit Artikelvorschauen unterschiedlicher Textlänge erzeugt bei klassischem CSS Grid entweder große Lücken, wenn jede Zeile auf die höchste Karte gestreckt wird, oder ein unruhiges Bild, wenn Karten frei fließen. Ein Masonry-Layout im Pinterest-Stil packt jede Karte in die aktuell kürzeste Spalte und vermeidet damit unnötige Lücken, ohne künstlich alle Karten auf dieselbe Höhe zu zwingen.

Gleichzeitig soll aber eine breitere, hervorgehobene Karte, die zwei Spalten überspannt, ihre eigenen inneren Elemente wie Titel, Meta-Zeile und Call-to-Action-Button exakt an denselben Spaltenlinien ausrichten, die auch die restlichen, einspaltigen Karten nutzen. Genau dafür braucht es subgrid, das eine verschachtelte Grid-Struktur an den Spurenraster des äußeren Grids ankoppelt, statt ein eigenes, unabhängiges Koordinatensystem zu öffnen.

2. Subgrid in Kürze: verschachtelte Grids an den Eltern-Raster koppeln

Normalerweise öffnet jedes verschachtelte display: grid-Element sein eigenes, unabhängiges Koordinatensystem aus Spalten und Zeilen, das nichts mit dem Spurenraster des umgebenden Grids zu tun hat. Der Wert subgrid für grid-template-columns oder grid-template-rows ändert das grundlegend: Ein Grid-Element, das selbst mehrere Spuren des Eltern-Grids überspannt, kann diese Spuren direkt übernehmen, statt eigene, potenziell abweichende Spurenbreiten zu definieren.

Das Ergebnis ist eine präzise Ausrichtung über Komponentengrenzen hinweg, die vorher nur mit manuell synchronisierten, fest kodierten Breitenwerten oder mit CSS Custom Properties nachgebildet werden konnte. Für Karten, Formulare oder Tabellenzeilen, die sich intern nach demselben Raster wie ihre Umgebung ausrichten sollen, ist subgrid inzwischen breit unterstützt und produktionsreif.

3. Masonry-Layout in Kürze: grid-template-rows: masonry

Das experimentelle Masonry-Layout wird über grid-template-rows: masonry aktiviert und weist den Browser an, die Zeilen-Achse eines Grids nicht mehr nach dem klassischen Grid-Algorithmus mit gleich hohen Zeilenspuren zu berechnen, sondern jedes Element in die Spalte mit dem aktuell wenigsten belegten Platz einzusortieren, ähnlich wie es JavaScript-Bibliotheken für Pinterest-artige Layouts seit Jahren manuell umsetzen.

Wichtig ist dabei eine oft übersehene Eigenschaft der Spezifikation: Masonry verändert ausschließlich die Achse, auf die es angewendet wird, in diesem Fall die Zeilen. Die Spalten-Achse bleibt ein ganz normales, explizites Spurenraster, definiert wie gewohnt über grid-template-columns. Genau diese Eigenschaft ist der Schlüssel dafür, dass sich Masonry und subgrid überhaupt sinnvoll kombinieren lassen.

4. Die Schlüsselerkenntnis: Masonry betrifft nur eine Achse, subgrid kann die andere nutzen

Weil ein Masonry-Grid mit grid-template-rows: masonry seine Spalten-Achse unverändert als reguläres, explizites Spurenraster behält, kann ein Kind-Element, das mehrere dieser Spalten überspannt, sein eigenes grid-template-columns: subgrid setzen und die Spaltenlinien direkt vom Eltern-Grid übernehmen. Die Zeilen-Achse dagegen bleibt für subgrid ungeeignet, weil Masonry dort keine festen, benennbaren Spuren erzeugt, sondern eine dynamische Packungslogik anwendet.

In der Praxis bedeutet das: subgrid funktioniert in einem Masonry-Kontext ausschließlich für die Spalten-Ausrichtung von Elementen, die mehrere Spalten überspannen, niemals für eine Zeilen-Ausrichtung. Diese Einschränkung ist keine Fehlerquelle, sondern folgt direkt aus der Funktionsweise von Masonry und sollte beim Layout-Entwurf von Anfang an mitgedacht werden, statt später als Überraschung aufzutauchen.

5. Konkretes Beispiel: eine hervorgehobene Karte mit subgrid-Spalten in einem Masonry-Raster

Das folgende Beispiel zeigt ein vierspaltiges Masonry-Raster, in dem eine hervorgehobene Karte zwei Spalten überspannt. Diese Karte nutzt grid-template-columns: subgrid, um ihre interne Aufteilung aus Bild, Titel und Call-to-Action exakt an den beiden überspannten Spalten des äußeren Grids auszurichten, statt eine eigene, unabhängige Zweispalten-Aufteilung zu berechnen.

Weil die Zeilen-Achse des äußeren Grids durch masonry dynamisch gepackt wird, bekommt die Karte ihre eigene Höhe intern über ein reguläres grid-template-rows, unabhängig vom Eltern-Grid. Nur die Spalten-Ausrichtung wird geerbt, die Höhe bleibt komponenteneigen und passt sich dem tatsächlichen Karteninhalt an.

.card-grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: masonry;
  gap: 1.5rem;
}

.card--featured {
  grid-column: span 2;
  display: grid;
  grid-template-columns: subgrid;   /* uebernimmt die 2 Spuren des Eltern-Grids */
  grid-template-rows: auto 1fr auto; /* eigene Zeilen, unabhaengig vom Masonry-Grid */
  gap: 1rem;
}

.card--featured .card-title {
  grid-column: 1 / -1;
}

.card--featured .card-meta {
  grid-column: 1;
}

.card--featured .card-cta {
  grid-column: 2;
  justify-self: end;
}

6. Ein vollständiges Karten-Raster mit Standard- und subgrid-Karten

In einem realen Projekt bestehen die meisten Karten eines Rasters aus einfachen, einspaltigen Elementen, die kein subgrid brauchen, weil sie ohnehin nur eine einzelne Spalten-Spur belegen. Subgrid lohnt sich gezielt für die Minderheit an mehrspaltigen, hervorgehobenen Karten, während der Rest des Rasters ganz normal ohne verschachtelte Grid-Deklaration auskommt.

Diese gemischte Architektur, ein Masonry-Grid als Basis mit vereinzelten subgrid-Karten für Sonderfälle, hält den Code übersichtlich und stellt sicher, dass subgrid nur dort eingesetzt wird, wo es tatsächlich einen Mehrwert bringt, nämlich bei Elementen, die mehrere Spuren des Eltern-Grids überspannen.

.card {
  /* normale Karte: keine subgrid-Deklaration noetig */
  grid-column: span 1;
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
}

.card-grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: masonry;
  gap: 1.5rem;
  align-tracks: start; /* verhindert vertikales Strecken innerhalb einer Masonry-Spur */
}

7. Browser-Support-Realität: warum die volle Kombination heute noch selten funktioniert

Subgrid selbst ist inzwischen breit in allen aktuellen Versionen von Chrome, Firefox und Safari verfügbar und gilt als produktionsreif. Masonry dagegen ist deutlich weniger weit fortgeschritten: grid-template-rows: masonry ist bislang primär in Firefox experimentell implementiert, während andere Browser-Engines einen alternativen Ansatz namens Item-Flow-Layout verfolgen, der syntaktisch und konzeptionell nicht identisch ist.

Diese Divergenz bedeutet, dass eine echte, spezifikationskonforme Kombination aus Masonry und subgrid derzeit realistisch nur in einem einzigen Browser vollständig funktioniert, während sie in allen anderen entweder komplett ignoriert wird oder auf einen abweichenden Mechanismus trifft. Für produktive Projekte ist das ein entscheidender Unterschied zu subgrid alleine, das längst breit einsetzbar ist.

8. Fallback-Strategie: ein normales Grid ohne Masonry als solide Basis

Der zuverlässigste Ansatz ist, das Layout grundsätzlich mit einem regulären, nicht-experimentellen Grid zu bauen, bei dem alle Karten in derselben Zeile dieselbe Höhe haben, und Masonry ausschließlich als progressive Verbesserung über eine Feature-Query nachzurüsten. Subgrid funktioniert dabei unabhängig vom Masonry-Fallback weiterhin normal, weil es nicht an die Zeilen-Achse gebunden ist, sondern rein die Spalten-Ausrichtung betrifft.

Diese Strategie liefert in jedem Browser ein funktionales, wenn auch nicht perfekt platzsparendes Ergebnis, während Nutzer eines Browsers mit Masonry-Unterstützung automatisch das dichter gepackte, optisch dynamischere Layout erhalten. Wichtig ist, im Fallback-Zweig keine Höhen hart zu kodieren, sondern weiterhin mit auto-Spuren zu arbeiten, damit der Übergang zwischen beiden Varianten visuell nicht abrupt wirkt.

.card-grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: auto;   /* solide Basis: alle Karten in einer Zeile teilen die Hoehe */
  gap: 1.5rem;
}

@supports (grid-template-rows: masonry) {
  .card-grid {
    grid-template-rows: masonry;
  }
}

9. Praxisempfehlung: wann sich die Kombination heute schon lohnt

Für interne Tools, Prototypen oder Projekte mit einer klar auf einen einzigen Browser eingeschränkten Zielgruppe, etwa ein internes Firefox-basiertes Dashboard, kann die volle Kombination aus Masonry und subgrid schon heute produktiv eingesetzt werden. Für öffentlich zugängliche Websites mit gemischtem Browser-Publikum bleibt die Kombination aus solidem Grid-Fallback und progressiver Masonry-Verbesserung der pragmatischere Weg.

Subgrid für die Spalten-Ausrichtung hervorgehobener Karten lässt sich davon unabhängig schon jetzt bedenkenlos produktiv einsetzen, unabhängig davon, ob Masonry überhaupt zum Einsatz kommt, weil subgrid selbst längst breite Unterstützung genießt. Wer heute JavaScript-Masonry-Bibliotheken durch native Lösungen ersetzen will, sollte das native Masonry deshalb konsequent hinter einer Feature-Query verstecken und nicht als einzige Lösung ausliefern.

10. Zusammenfassung

11. FAQ: Subgrid und Masonry kombiniert: Das Wichtigste auf einen Blick