CSS Masonry ohne JavaScript: der native Grid-Weg

Der Kunde schickt dir drei Dutzend Referenzfotos für seine neue Portfolio-Seite: Hochformat, Querformat, ein paar quadratische Screenshots. Sein Wunsch klingt simpel – „so wie bei Pinterest, ohne diese hässlichen Lücken". Gemeint ist ein Mauerwerk-Raster, bei dem jede Kachel ihre natürliche Höhe behält und die Spalten trotzdem lückenlos ineinandergreifen. Jahrelang hieß die Antwort darauf: eine JavaScript-Bibliothek einbinden, die nach dem Laden jede Kachel ausmisst und von Hand platziert. Genau diese Bibliothek ist das Problem – und seit 2026 brauchst du sie nicht mehr.

CSS Masonry ohne JavaScript: Schluss mit Masonry.js

Das Mauerwerk-Layout – im Englischen „masonry" – ist der Klassiker, den das normale CSS-Grid bisher nicht konnte. Ein Grid ordnet Inhalte in strenge Reihen und Spalten; sind die Kacheln unterschiedlich hoch, entstehen in jeder Reihe Lücken bis zur Höhe des größten Elements. Das Mauerwerk-Layout verschiebt stattdessen jede Kachel so weit nach oben, wie Platz ist, und lässt die Spalten unabhängig voneinander wachsen.

Weil CSS das nicht beherrschte, sprang JavaScript ein. Bibliotheken wie Masonry.js laden zusätzlichen Code – das verbreitete Paket bringt rund 16 Kilobyte an gezipptem JavaScript mit –, warten, bis der Browser die Seite gerendert hat, messen dann die Höhe jeder Kachel und berechnen anschließend die Positionen. Dieses Nachladen und Nachrechnen ist der Haken: Der Besucher sieht erst ein zusammengestauchtes Raster, das eine Sekunde später neu springt. Für kleine Agenturen bedeutet jede solche Abhängigkeit außerdem Wartung – ein weiteres Paket, das aktualisiert und auf Sicherheitslücken geprüft werden will, derselbe Ballast, den auch das CSS-Karussell ohne JavaScript loswird.

Der Streit, der das Feature jahrelang blockierte

Dass natives Masonry so lange auf sich warten ließ, lag nicht an fehlendem Interesse, sondern an einem Grundsatzstreit zwischen den Browserherstellern. Das Chrome-Team wollte das Mauerwerk-Layout als eigenen Anzeigetyp umsetzen, also als neuen Wert für die display-Eigenschaft. Das WebKit-Team hinter Safari hielt dagegen, man solle die Fähigkeit in das bestehende Grid integrieren und schlicht grid-template-rows: masonry schreiben können. Beide Seiten veröffentlichten ausführliche Argumente, und die CSS Working Group diskutierte die Frage über Jahre – mit dem Ergebnis, dass Entwickler gar nichts bekamen.

2026 fand sich schließlich ein dritter Weg: ein eigener Anzeigetyp, aber mit vertrautem Namen – display: grid-lanes, die „Grid-Spuren". Die Idee dahinter ist der Kompromiss, der beide Lager zufriedenstellt. Du bekommst die volle, bekannte Spalten-Syntax des Grids, aber in einem Modus, der die Zeilenbindung aufhebt und die Kacheln spaltenweise nach oben packt. Anfang 2026 wurde zudem die Eigenschaft, die die Platzierung steuert, in flow-tolerance umbenannt – ein Zeichen dafür, dass an der Spezifikation noch gefeilt wird.

So baust du das Raster – drei Zeilen genügen

Der eigentliche Code ist ernüchternd kurz. Für ein Galerie-Raster, das sich automatisch an die Breite anpasst, reichen:

.galerie {
  display: grid;         /* Rückfall für alte Browser */
  display: grid-lanes;   /* moderner Mauerwerk-Modus */
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 1rem;
}

Die erste display-Zeile ist bewusst doppelt gesetzt: Browser, die grid-lanes noch nicht kennen, ignorieren den unbekannten Wert und bleiben beim gewöhnlichen Grid – dazu später mehr. Die grid-template-columns-Zeile ist dieselbe, die du aus dem Grid-Alltag kennst: Sie legt so viele Spalten an, wie bei mindestens 250 Pixel Breite hineinpassen, und verteilt den Rest gleichmäßig. Den Rest – das Verschieben der Kacheln nach oben – erledigt der Browser.

Die Platzierung mit flow-tolerance steuern

Standardmäßig packt der Browser jede neue Kachel in die momentan kürzeste Spalte, damit die Spalten möglichst gleich lang bleiben. Das sieht ausgewogen aus, kann aber dazu führen, dass die Lesereihenfolge durcheinandergerät. Mit flow-tolerance legst du fest, wie streng der Browser auf gleiche Spaltenhöhen optimiert: Ein höherer Wert erlaubt ihm, Kacheln näher an ihrer ursprünglichen Reihenfolge zu platzieren, auch wenn die Spalten dadurch ungleicher werden. Genau dieser Regler ist der Hebel für das Barrierefreiheits-Problem, das gleich noch kommt.

Warum das die Core Web Vitals schont

Der technische Gewinn liegt im Zeitpunkt der Berechnung. Die JavaScript-Variante konnte erst arbeiten, nachdem der Browser die Seite einmal aufgebaut hatte – sie brauchte die gerenderten Höhen, um zu rechnen. Das Ergebnis war ein sichtbarer Sprung: Erst steht der Inhalt an einer Stelle, dann wird er umsortiert. Dieser Sprung schlägt direkt auf die Kennzahl Cumulative Layout Shift durch, einen der Werte, die Google unter den Core Web Vitals misst.

Beim nativen Mauerwerk entfällt dieser Umweg. Der Browser kennt die Positionen, bevor er den ersten Pixel zeichnet, und baut das Raster in einem Rutsch korrekt auf. Kein Nachladen, kein Umspringen, keine zweite Layout-Berechnung im Hauptthread. Zugleich fällt eine ganze JavaScript-Abhängigkeit weg – der gleiche doppelte Vorteil aus Tempo und weniger Wartung, den auch andere moderne CSS-Werkzeuge bringen, über die der Überblick zu den modernen CSS-Features 2026 informiert. Für eine Bildergalerie lohnt es sich, diesen Effekt mit sauber optimierten Bildern im WebP- oder AVIF-Format zu kombinieren.

Der Haken bei der Barrierefreiheit

Hier kommt der Punkt, den du im Kundenprojekt kennen musst, bevor du das Feature einsetzt. Weil der Browser die Kacheln nach Spaltenhöhe verteilt, stimmt die sichtbare Reihenfolge nicht mehr zwingend mit der Reihenfolge im Quelltext überein. Für Menschen, die mit der Maus über die Bilder scrollen, ist das egal. Für Menschen, die mit der Tastatur durch eine Seite navigieren, nicht: Der Fokus springt dann in einer Reihenfolge durch die Elemente, die optisch unvorhersehbar wirkt.

Der Accessibility-Fachmann Manuel Matuzović weist in einer Analyse darauf hin, dass ein solches Raster dadurch das WCAG-Erfolgskriterium 2.4.3 („Fokus-Reihenfolge") verfehlen kann – die Regel, die verlangt, dass die Navigationsreihenfolge sinnvoll und nachvollziehbar bleibt. Seine Empfehlung läuft auf drei Dinge hinaus: das Raster mit der Tastatur bei verschiedenen Bildschirmbreiten testen, den flow-tolerance-Wert erhöhen, um Quelltext- und Anzeigereihenfolge näher aneinander zu bringen, und auf ein reines Grid zurückfallen, wenn sich die Zugänglichkeit nicht sauber lösen lässt. Eine zusätzliche Eigenschaft namens reading-flow, die die Fokusreihenfolge gezielt steuern soll, ist in Arbeit, aber noch nicht breit verfügbar.

Für Agenturen heißt das konkret: Für eine reine Bildergalerie ohne Links in den Kacheln ist das Risiko gering. Sobald die Kacheln aber anklickbar sind – Projektkacheln, die zu Fallstudien führen, Blog-Teaser, Produkt-Vorschauen –, gehört der Tastaturtest zum Pflichtprogramm. Das ist kein Nice-to-have, sondern seit 2025 für viele gewerbliche Seiten Teil der gesetzlichen Pflicht, wie der Überblick zur barrierefreien Website-Pflicht zeigt.

Der ehrliche Blick auf den Browser-Support

Jetzt die Einordnung fürs Kundengespräch. display: grid-lanes ist noch kein Feature, das überall gleich funktioniert. Safari hat es mit Version 26.4 als erster Browser standardmäßig aktiviert; Chrome, Edge und Firefox haben Implementierungen, die bislang hinter einem Schalter stecken und im Lauf des Jahres nachziehen sollen. Nach den gesammelten Nutzungsdaten liegt die weltweite Unterstützung damit Stand Mitte 2026 erst bei rund einem Zehntel – von einem Baseline-Feature, das du bedenkenlos überall einsetzt, ist das noch entfernt.

Die entscheidende Frage ist deshalb auch hier nicht „kann ich das nutzen?", sondern „was passiert, wenn der Browser es nicht kann?". Und die Antwort steckt schon in der doppelten display-Zeile von oben: Ein Browser, der grid-lanes nicht versteht, verwirft diesen Wert und bleibt beim davor gesetzten display: grid. Der Besucher sieht dann kein Mauerwerk, sondern ein ordentliches, gleichmäßiges Raster mit ein paar Lücken – sauber, vollständig, nutzbar. Nichts bricht. Genau dieses Prinzip der progressiven Verbesserung ist der verlässliche Weg, neue CSS-Fähigkeiten einzusetzen, wie ihn auch der Beitrag zu Baseline 2026 beschreibt.

Was das für kleine Agenturen heißt

Natives Masonry ist 2026 vom jahrelangen Streitthema zu einer greifbaren Technik geworden. Mit drei Zeilen CSS ersetzt du eine JavaScript-Bibliothek, die Code lädt, das Layout springen lässt und gepflegt werden muss. Das Ergebnis läuft flüssiger, weil der Browser vor dem ersten Pixel rechnet, und es spart dir eine Abhängigkeit. Der Preis ist Aufmerksamkeit an zwei Stellen: beim Browser-Support, den die doppelte display-Zeile aber risikofrei abfedert, und bei der Barrierefreiheit, sobald die Kacheln anklickbar werden. Wer das im Kopf hat, kann den Pinterest-Wunsch des Kunden heute sauber erfüllen – und muss dafür keine 16 Kilobyte Fremdcode mehr ausliefern.