CSS Grid Lanes lands in Safari — native masonry layouts without a JavaScript library
Pinterest-style masonry layouts — cards of different heights packed together with no gaps — have been a frustrating gap in CSS for years. The options were a JavaScript library that measured every element, or a CSS columns hack that broke reading order and accessibility. After a long debate inside the CSS Working Group, the spec settled on a name, grid-lanes, and Safari became the first browser to ship an implementation.
What Grid Lanes does
Grid Lanes adds a layout mode that defines tracks on one axis and lets items pack tightly along the other — so cards of varying heights nestle together without the ragged gaps a normal grid leaves behind. You write it with familiar grid syntax:
The crucial difference from the old CSS columns trick is ordering. The columns hack flows items top-to-bottom down one column before starting the next, which scrambles the relationship between visual order and DOM order — a real problem for keyboard and screen-reader users. Grid Lanes preserves DOM order: content that's earlier in the HTML groups toward the start of the container, and lazy-loaded items append at the end without reshuffling what's already on screen.
How we got to grid-lanes
This has been a slow-cooking standard. Mozilla first implemented a masonry experiment back in 2020 using display: grid; Apple's WebKit team picked the work up and refined it; Chromium experimented with a different syntax behind a flag. Those competing approaches drove the Working Group debate over how the feature should actually behave and what to call it. The resolution — a distinct grid-lanes keyword rather than overloading display: masonry — sidesteps clashes with the many libraries that already use the word "masonry," and Safari shipped against the settled spec first.
Should you use it yet?
Not in production without a fallback. As of now, support is effectively Safari-first; the other engines are updating their implementations to the finalized syntax but aren't there in stable channels. The safe pattern is progressive enhancement — wrap the masonry styling in an @supports check and let unsupported browsers fall back to a regular grid:
Two things are worth doing now: write that @supports guard so you're ready the moment the other browsers ship, and test the keyboard and screen-reader experience regardless — packing order can still surprise users even when DOM order is preserved. The long wait for native masonry is nearly over; this is the moment to learn the syntax, not yet the moment to drop your fallback.