Grid Lanes gets a Field Guide — and a fourth layout primitive to argue about
Iris Calderón
You have ten cards of unequal heights, and the layout you actually want is something between Grid and Multicolumn: items flow across lanes, but the cascade doesn't fight you when one card grows. Today that means a hand-tuned Grid with grid-auto-rows math, a Multicolumn that breaks the moment a child is too tall, or a JavaScript layout library. WebKit just published a Field Guide for a different answer — a new top-level layout primitive called Grid Lanes — and an entire reference site to teach it.
The Field Guide lives at gridlanes.webkit.org: a playground, a cheat sheet, and six demos that put Grid Lanes next to Flexbox, Multicolumn and Grid on the same content. That side-by-side comparison is the point of the site. You see where existing layout modes run out of road, and what Grid Lanes does in their place.
The new display value
You opt in by switching the layout mode of a container:
.gallery {
display: grid-lanes;
}
That's the entry point. From there, the primitive ships with two modes — waterfall and brick — that change how items flow into lanes. The Field Guide is the place to watch them side by side; the takeaway worth noticing is that Grid Lanes treats the choice between flow shapes as a first-class property of the layout mode, not something you simulate with autoflow tricks.
Track sizing should feel familiar
The track-sizing surface deliberately mirrors what you already write in CSS Grid. Per the Field Guide, tracks accept:
frunits, fixed lengths and percentagesauto,min-content,max-contentandfit-content()minmax()for floor-and-ceiling sizingrepeat()with bothauto-fillandauto-fit
If you've internalised Grid track sizing, you have most of the vocabulary already. That's a deliberate ergonomic choice — every track-sizing concept you use in grid-template-columns has a home in Grid Lanes too, which means the learning curve is mostly the new bits, not a rewritten language.
Placement, gaps and a new knob
The other half of any layout primitive is placement and spacing. Grid Lanes covers gap, spanning tracks (one item occupying more than one lane), and explicit placement (you put an item where you want it instead of letting it flow into the next free slot).
The Field Guide also introduces flow-tolerance, a placement and spacing control specific to lane-based flow. The exact semantics are best read in the source while the spec text is fresh, but its presence on the placement surface is the bit worth noticing. It's a knob that Multicolumn never gave you and that Grid only emulated by hand-placing every item.
Devtools join in
Inspecting lane-based layouts is where DOM order and visual order tend to drift, which is also where most layout debuggers go quiet. Safari's Web Inspector has shipped an "Order Numbers" overlay specifically for this — per the source, it visualises DOM order during layout. When something looks misplaced you check the numbers, then decide whether to reach for a placement property or re-shape your source. Small affordance, but it pays for itself the first time a card jumps to the wrong lane.
Where it lands today
Grid Lanes works in Safari 26.4 and up. That makes the Field Guide engine-specific reading right now. The source doesn't claim cross-browser baseline status, and neither does this post. If you ship to a broad audience, this is @supports territory at best; if you're prototyping in Safari, it's something you can drop into a real layout today and learn at the same time.
On your next layout
Before reaching for display: grid-lanes, write down the layout you can't build today and what's stopping you. If the blocker is "items of different heights flowing into lanes with controllable gaps and placement," this is the primitive built for that shape. If the blocker is two-axis alignment of a known grid, CSS Grid still wins; if it's single-direction content distribution, Flexbox is still the cleaner reach. The Field Guide's comparison demos are the fastest way to see which side of those lines your design sits on — and the cheapest way to find out whether the new primitive earns its place in your toolkit at all.
Source: WebKit Blog (webkit.org)