Masonry heißt jetzt Grid Lanes. Ausliefern würde ich es trotzdem noch nicht

Safari 26.4 hat natives Masonry stabil. Fünf Jahre Namensstreit sind vorbei. Nur zerschießt die neue Layout-Engine deine Tab-Reihenfolge, und das ist ein WCAG-Fail.

Fünf Jahre hat die CSS Working Group über einen Namen gestritten. collapsed-grid, grid-stack, masonry-grid, compact-grid, staggered-grid, axial-grid. Jen Simmons hat 2024 öffentlich geschrieben, dass sie von dem Tempo enttäuscht ist. Jetzt heißt es grid-lanes, Safari 26.4 hat es stabil ausgeliefert, und ich habe letzte Woche zwei Abende damit verbracht.

Kurzfassung: Die Syntax ist gut. Der Rest ist noch nicht so weit.

Wie es funktioniert

Masonry ist das Pinterest-Layout. Spalten fixer Breite, Elemente unterschiedlicher Höhe, jedes neue Element rutscht in die Spalte, die gerade am kürzesten ist. Bis jetzt ging das mit column-count (falsche Lesereihenfolge, Elemente laufen vertikal) oder mit Masonry.js und Konsorten, die Positionen in JavaScript ausrechnen und absolut positionieren. Beides Krücken.

Nativ sieht das so aus:

.gallery {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 16px;
}

Das war der ganze Trick. Keine Höhenangaben, keine Item-Klassen, kein Resize-Observer. grid-template-columns funktioniert wie im normalen Grid, gap auch, und Elemente lassen sich weiterhin explizit platzieren:

.gallery .feature {
  grid-column: -3 / -1;
}

Ein echtes neues Property gibt es auch: flow-tolerance. Default ist 1em. Es sagt dem Packing-Algorithmus, ab welchem Höhenunterschied zwei Spalten überhaupt als unterschiedlich lang gelten. Bei Toleranz 0 landet jedes Element in der mathematisch kürzesten Spalte, was in der Praxis heißt: die Reihenfolge springt permanent. Bei flow-tolerance: infinite füllt der Browser stur der Reihe nach von links nach rechts. Das Property hieß bis Januar 2026 übrigens item-tolerance, falls du auf ältere Tutorials stößt.

Der Haken

Manuel Matuzovic hat das Ding auseinandergenommen. Wiener, macht seit Jahren die gründlichste Accessibility-Arbeit im deutschsprachigen Raum, und sein Titel sagt schon alles: "Your Grid Lanes will likely fail WCAG 2.4.3."

Das Problem steckt in der Mechanik selbst. Der Browser platziert Elemente danach, wo sie am weitesten oben landen. Die visuelle Reihenfolge hat damit nichts mehr mit der DOM-Reihenfolge zu tun. Der Tab-Fokus folgt aber dem DOM. Also springt er in seinen Tests von Spalte 2 nach Spalte 3 nach Spalte 1 zurück. Für Tastaturnutzer ist das nicht vorhersehbar, und genau das verlangt WCAG 2.4.3 (Focus Order).

Bei einer reinen Bildergalerie ohne Links ist das egal. Sobald in den Kacheln Links oder Buttons stecken (also bei jeder Projekt-, Blog- oder Produktübersicht, für die man Masonry eigentlich haben will), ist es ein handfester Fail.

Die Lösung heißt reading-flow: grid-rows. Das schaltet den Fokus auf die visuelle Reihenfolge um. Nur: Safari kann Grid Lanes, aber kein Reading Flow. Chrome kann Reading Flow, hat Grid Lanes aber noch hinter einem Flag (about:flags, Suche nach "CSS Masonry Layout", ab Version 140). Die beiden Features, die man zusammen braucht, sind gerade in unterschiedlichen Browsern.

Was ich damit mache

Matuzovics Empfehlung ist die richtige, und sie ist auch die, die ich in Projekten einsetze:

.gallery {
  display: grid;
  grid-template-columns: repeat(3, 1fr);

  @supports (display: grid-lanes) and (reading-flow: grid-rows) {
    display: grid-lanes;
    reading-flow: grid-rows;
  }
}

Beide Bedingungen im selben @supports. Kann der Browser nur eins von beidem, bleibt es beim normalen Grid mit gleich hohen Zeilen. Das ist heute die Realität für praktisch alle User: Safari fällt raus, weil Reading Flow fehlt, Chrome, weil Grid Lanes noch geflaggt ist.

Klingt sinnlos, ist es aber nicht. Das CSS steht, wenn Chrome im Lauf des Jahres nachzieht, und bis dahin richtet es keinen Schaden an. Kostet drei Zeilen.

Wer nur die halbe Prüfung schreibt und Safari damit die kaputte Fokusreihenfolge unterschiebt, sollte wenigstens flow-tolerance: infinite dazusetzen. Dann packt der Browser zeilenweise, DOM- und Sehreihenfolge decken sich weitgehend, und man verliert im Wesentlichen nur das unregelmäßige Ausfransen am unteren Rand. Ehrlich gesagt: dann kann man auch gleich beim Grid bleiben.

Warum ich mich trotzdem freue

Masonry.js und Isotope haben nie sauber funktioniert. Absolut positionierte Elemente, Layout-Neuberechnung bei jedem Resize, Bilder, die nach dem Nachladen alles verschieben, und Print-Styles, die man vergessen kann. Ein Kundenprojekt hatte deswegen jahrelang einen Layout-Shift-Wert, den ich mit keinem Trick unter 0.1 bekommen habe.

Das ist erledigt, sobald die Browser gleichziehen. Gleiches Muster wie bei Anchor Positioning, View Transitions und CSS Carousels: Was gestern eine Library war, ist morgen eine Zeile CSS.

Nur eben morgen. Nicht heute.

Sources: