Fun with grid-lanes - CSSDay 2026

Hi, it's great to be here. Fun with CSS grid-lanes, let's get started.

I'm gonna date myself a little bit here. The year is 1996, I'm 16 at the time. I'm discovering the Internet, becoming an absolute fan of the web at first sight. You can see me sitting in front of the family computer, browsing the web.

Let's zoom in on the computer screen. Who here recognizes the Netscape logo? It was great, right? Anyway, sites in '96 were quite the work of art. Let's review a few.

Let's review a few here. Credits to the web design museum for the screenshots. https://www.webdesignmuseum.org/gallery/year-1996/ (Scroll down) Very image-heavy, very colorful, lot's of details and content. Pixel-perfect, no responsiveness of course. And, oh surprise, lot's of print style, waterfall style, layouts made up of columns with different size items. Is this masonry layout, 30 years ago? Well, we'll see in a bit.

(Hover over the box.) Before we do, let's take a moment to appreciate where we come from. You see, to create any part of these sites at the time, we needed a lot of images. Even just for a fancy box like this, we'd have to create a div with 9 children elements, and make custom images for each of the corners and sides, repeating them as needed, to create the illusion of a single box.

(Hover and click buttons). And for buttons like these, that have hover and active states, you'd have to make custom images, for each button and each button state (normal, hover, active), and include the text in the images, if you wanted a fancy font. And then handle the swapping of images in JavaScript. I personally used Dreamweaver because it had a cool image rollover feature that wrote the code for me.

Images were the name of the game. We'd create sites in photoshop, slice them up in tiny little pieces, place everything in tables inside of tables inside of tables, position everything with pixel values, to make the end result look exactly like the initial design. It wasn't elegant, but it was all we had.

But, these constraints, they fueled our creativity, and forced us to invent workarounds to achieve what we needed. We were doing things that weren't meant to be possible, and it's how we pushed the platform forward. And that's still how things work today.

The playground got BIGGER, much much bigger. But it's still a playground It's fun to make things and discover new use cases.

And, at heart, I'm still this 16 year old kid. Sitting in front of the computer, having fun with the web I still just love creating things. Except I have kids of my own now. So I do things "for them" but really it's just an excuse to continue playing.

Like here, I'm combining offset-path to animate the planets along their orbits. And anchor positioning to keep the labels next to the planets. No JS, no other markup needed. Fun: make them go super fast.

Here, learning about the dialog element and commandfor button attributes. Each hole in the ground contains a dialog which is displayed randomly. The dialog is a mole. It contains a single button which, when clicked closes the dialog. Again, no JS, just some fun CSS and HTML.

Or making math fly! Because why not. A fun way to learn about mathml, and 3D transform.

Jake covered custom selects yesterday. That's a feature I've been playing with for a long time now, super exciting to see it get to browsers. For this one, I was curious to see how much you could customize the picker popup part. Turns out you can remove it entirely, and let the options float on the page.

I like using things it ways they weren't intended to be used too. A great way to discover potential improvements and use cases. Here is focusgroup, a great accessibility feature that gives you arrow key navigation for complex widgets like toolbars or menus, and all in HTML, no JavaScript. Here, I'm using it to create a little pacman game, with 0 JavaScript for the movement.

In the same theme of doing things that weren't intended, here's pongrid. Super simple game, where the rendering is done in CSS grid. Each pixel is a grid cell. And re-drawing the game at each step of the loop means updating the grid-area of the various game entities.

Finally, cranking things up to 11 can be fun too. Here I created a new kind of popup hell by chaining hundreds of popups using anchor positioning. Only the red popup is hooked up to following my cursor. All the other ones follow due to anchor positioning. This was a fun one to create, it actually helped me find a bug in Firefox, which I reported, and which got fixed. Now I'm only scratching the surface of what you can do with CSS. Some people go much further than I do. I mean, you were here for Lyra's talk yesterday, right? But the point is, by doing these things: a) I learn about these new features in a much deeper way than I would normally have. b) And I sometimes identify issues, or new use cases, which can help make the platform better for everyone. I don't want to seem out of touch with the reality though. You don't have to go and take hours away from work or life to go and do these things. But I really encourage playing, and it can be as simple as finally trying out a new CSS feature, which you've heard, on a new project.

First, because computers are fun. And that's probably enough of a reason. But also, wearing my browser vendor hat on for a minute: this is how the web evolves. If the web became that much more capable, do we still need to play and explore? Well, if we don't play with the features of the web platform, actual html, css, js features, we end up pushing the platform forward far less and that's bad for everybody. For our beloved platform to remain capable and interoperable we, all together as a community, need to be constantly filling the pipe with new features so that these features can then become standardized and then interoperable based on actual usage and real feedback. There's risk in simply copy/pasting from old solutions Using AI that doesn't know about the latest features, or using only framework-provided solutions which abstract primitives away A platform that stagnates is not a great platform. We need to keep playing with the web, explore its edges, and even go beyond them.

I want to give a quick analogy on this: The web doesn't evolve by writing specs in a vacuum, and sometimes agree on them. The web evolves because developers ask for things, try new things and experiment, and then complain loudly enough about them Specs happen later. It's a bit like a wind tunnel to test planes. Engineers who work on planes don't start by standardizing how to build them First, they build experimental prototypes. They shake them in wind tunnels. They see where things break in the real world, and discover turbulences. Only then do they write the rules for safe flight. The more we can be the web's wind tunnel, the better for our industry.

Now let's switch gears. And talk about another feature which appeared a long time ago on websites, before any browser had support. then got prototyped in 1 browser years ago. And it's only now getting standardized and implemented in multiple browsers. Based on actual usage and feedback. Masonry, aka grid-lanes.

Just so we're all on the same page, and in case you've never seen it, what pops up in people's mind when we say "masonry" is often something like Pinterest's layout. Column arrangement of items of varying heights, with no fixed rows.

In CSS, here's what grid-lanes is, at a high level: 1. It's a new, built-in, layout primitive in the borwser. No JS code needed, just a few lines of CSS code. Great for performance. 2. There's a new name: grid-lanes, get used to it! 3. It's not a special kind of grid. It does share some things with CSS grid, but it's fundamentally different in how things are placed. 4. Grid-lanes is more like 1D, like flexbox. You only control the lanes of your layout, not the other direction. 5. Grid-lanes isn't only vertical It can be horizontal too. And it's not only top to bottom. It can be reversed. 6. You don't have to have same-size lanes only. Lanes can be of any size and different from each other. In fact, the full power of the `repeat()` function and fr units can be used. 7. This algorithm is opportunistic, and sometimes can seem chaotic. That's the default placement. But you can still control the placement of items if you want. You can assign items to specific lanes. Or make them span multiple lanes. 8. Visual order is not DOM order. Items that appear later in the DOM may appear visually above earlier items. Same with flexbox and grid. So beware of keyboard tabbing order.

First, where can you use this? Pretty much everywhere, but with caveats: Safari has shipped it back in March. Chrome and Edge, my team is working on the implementation right now, and we're nearing the finish line. You can use it by enabling the #css-grid-lanes-layout flag on the about://flags page. Firefox has had a prototype for a long time. But the spec has evolved since then. You can follow their implementation progress on bugzil.la/grid-lanes.

Let me address the elephant in the room with masonry. - Is Masonry actually something people want? I mean, it's been on Pinterest for a long time, do people still want it? Is it still fashionable? Short answer: yes - 2nd most voted missing feature in State of CSS 2025, - 3rd in 2024 - Is it any good? I mean, it's chaotic right? Not easy to know how to visually scan it. Well, my answer to this is: it's a very creative layout system that allows for a lot of freedom and different results. Yes, if you have content that must be read in a specific order, it might not always work for you. But, as I hope I'll show, you can do a lot of really good things And, you know, let creatives be creative I guess. Now before getting into teh technical details, why don't we take grid-lanes to the wind tunnel, and shake it a bit.

First, what if we pushed it to its limits? Here is a grid-lanes layout with 500 items. Just for fun, their height is also being animated.

500 items is no fun. What if we went all the way to 10,000? All of these have different sizes and colors and the gap between them is animated. Creating an abstract steps pattern.

If you paid attention before, you might have seen that it didn't look like a typical masonry layout because items stacked from the bottom. This is another like that one. The fill direction is reversed here which makes masonry kind of behave like it has gravity, with items wanting to fall as far down as they can. So, that's another fun one, mixing masonry with reversed direction, and view transition in this case to animate the fall of the balls.

And here is one last fun example, mixing 2 masonry layouts, one going down, the other one going up.

First, let's talk about naming here. -> Lanes This might be new to some of you. Masonry is the way that most people have come to know about this type of layout. It's still the most common name for it. But, it actually comes from a popular JS library by David DeSandro. You can use this lib in browsers today, and it's been very popular for a long time. Mozilla was the first to provide an experimental implementation of this layout, right after they implemented CSS grid, so almost 10 years ago now. When they did, they preserved the name "masonry" But now, in a crazy turn of events, the latest spec, and current implementations, don't use that term anymore. The new name grid-lanes. Think of it as swim lanes, or maybe traffic lanes. And the reason for this is that masonry is 1D, you only define layout along one axis.

Grid-lanes is good at occupying empty space. But the experience you're designing might not revolve entirely around this. And having a slightly less space-efficient alternative may be fine. If so, then grid-lanes can be a great progressive enhancement. Define both display:grid and display:grid-lanes, and non supporting browsers will ignore the second.

Let's talk about shape and orientation first. That's what defines the visual aspect of your layout.

To do this, we'll go through these 5 steps. On the right is a stack of DIVs, no special layout. 1. opt-in to grid lanes by using the new display type. Small visual difference here because I'm using gap. display:grid-lanes turns it into a single lane, vertical by default, with some gap. 2. Then, to set the orientation for your lanes, you can set either grid-template-columns, for columns or grid-template-rows for rows. The browser does the right thing for you automatically, just based on which of these properties is set. 3. Then control the shape and number of your lanes. You can reuse the full power of the grid track sizing syntax, even using the repeat function, the fr unit, and the auto-fill/fit keywords. Here we're creating 4 lanes that are 2fr 1fr 3fr 1fr wide. 4. One other thing we can do to control the shape of our layout is customize how many lanes specific items span. For example here, the pink items span 2 lanes. 5. And finally, you can also dictate specific lanes for your items, just like in grid. Again though, only along the lane axis, because that's the only axis that exists. Here I'm making the the blue item go to the first lane, by using the grid-column property. You'd use grid-row in a row-oriented layout. So, that's for the shape of your layout.

But that's not all you can do. There are ongoing discussions for adding more options to control the direction of your layout. This is very similar to flexbox where you can choose an orientation, and a starting position with row/column or row-reverse/column-reverse. With grid-lanes, same idea, you pick an orientation: row/column. And a direction to fill the layout: left/right for row, or top/bottom for column.

I said before that you can use the full power of the grid track sizing syntax to define your lanes. So you can do all of the above, mixing units, using fr, using repeat and minmax, etc.

But, there's one more thing you can do, which isn't possible with grid: intrinsic sizing of lanes. The grid-lanes spec relaxes the auto-repeat syntax to allow intrinstic sizes, such as `auto` inside repeat() syntax. In regular grid, repeat(auto-fill, ...) requires definite track sizes (like 200px) to calculate how many repetitions fit. Grid-lanes (CSS Grid Level 3) relaxes this. Lanes can have content-dependent sizes. This can be very useful: when you don't know the size of your items ahead of time when writing the stylesheet. This creates as many columns as fit, where each column sizes to its content (e.g., images of natural width).

Now that we have a shape for the layout, let's talk about flow. Beyond the general shape of the thing you are building, it's very important to consider the order in which items are placed.

The same general shape can be created by using different layout types, so, ultimately it all depends on how you want your items to flow through that shape. Here is flex, multicol, and grid-lanes. flexbox and multicol: same thing you get columns with items flowing down each column one by one. grid-lanes: a big difference in the order of elements. Because grid-lanes is opportunistic. It doesn't like to leave gaps. It'll try to fill the shortest lane first. And this is what gives us this criss-cross pattern. Almost like rows in this case. So, similar shapes, very different flow.

But, while I just said that the previous grid-lanes which had 3 columns, created "rows" of items, I want to make sure you take this away: there are no rows to speak of in a column orientation grid-lanes layout. Here is an illustration of this. On the left, items have mostly the same height, and therefore they are placed in a way that looks like rows. On the right, items have very different heights, and you can see how rows are nowhere to be seen. Not only are things not aligned, but they're out of order too.

Here is another way to illustrate the difference. Here we have flex, and I can show the flow of items going down predictably one column after the other. Next, multicolumn, which is almost the same shape the only difference here is that multico supports fragmentation. So certain items start in one column and end in the next. But the flow of items is the same. But now, switching to grid-lanes, you can see the difference. Items get re-order quite drastically. And the flow is this criss-cross pattern. Very different from the previous two.

We can also compare this to grid. Grid gets you ... well, a grid. Which can sometimes lead to gaps when items don't all have the same size. It's easy to think that grid-lanes is basically a grid without the gaps. So let's remove the gaps, virtually, from this grid. And now let's switch the grid-lanes. Again, big difference in the flow of items. The placement algorithm is very different between grid-lanes and grid. So, keep in mind, grid-lanes doesn't start from grid and then squishes everything closer together. It fills lanes item by item, always making a decision as to which lane is shortest.

In fact, let's go through the placement algorithm step by step to understand this a little better. Every time I click the Step button, a new item is added, and the total height of each column is displayed. 2 things to remember: - always pick the shortest lane - writing direction: ltr -> go through lanes in this order and then wrap around.

This brings us to something quite important, called flow-tolerance. Why do we have this somewhat chaotic way of placing items? Going back and forth between lanes? Masonry is trying to solve two conflicting goals at once: 1. Produce a result that's visually balanced. Where no one lane is much much longer than the others, and where we don't have big gaps. So, attempting to fill lanes that aren't yet filled. 2. Preserve the DOM order as much as possible. So, attempting to place items predictably, from left to right for example. These are not always compatible. If you went strictly one lane after the other, you might end up with a very unbalanced layout, with one very long lane for example. On the other hand, if you always picked exactly the shortest lane, you might end up with a very chaotic layout, with items placed in a seemingly random order. That's where flow-tolerance comes in. And where you have control. With a flow-tolerance value of 0, you get the most strict placement. The overall layout is balanced because you _always_ pick the shortest lane. But you also get the most DOM order disruption. With a flow-tolerance value of infinite, you get no disruption at all you always pick the next lane, because they're always considered tied. But you also get the most visually unbalanced results, with long lanes. The 1em value is a default value that tries to strike a balance between the two. Because this way, very tiny differences in height are ignored, which helps keep the flow a little more predictable. You can set the value of the `flow-tolerance` property to whatever works best for your content and design.

Let's summarize what we just learned.

Adding a starting-style transition with a bit of a delay, creating the appearance of a staggered entry animation, without JS.

Or, take it further, and combine it with scroll triggered animation.

Another example, showing a 2 column layout except it's not really 2 column, it's more like 1/3 - 2/3. and the text doesn't always start flush with the image, creating a more dynamic and less rigid layout.

Infinite loading of content while the user scrolls works great with grid-lanes. On this demo, I'm using an IntersectionObserver to detect when the user is getting close to the end of the list, and then I add a few more items to it. Because grid-lanes fills lanes, trying to balance them as much as possible, the new items get nicely added to the end of the layout, without leaving gaps, and without any JS code needed.

This sample demonstrates specific lane placement. Each item has a `grid-column` value that's set to the column it belongs to. All I have to do when I want to move an item is change the grid-column value. It's combined with view transitions to get a smooth animation for free. - You couldn't do this with CSS grid without leaving gaps between sticky notes. - You could do this with CSS multicol. But for this, you'd have to make sure the items are contained in column wrapper divs, and prevent fragmentation, which happens with multicolumn. And then you'd have to change the order of items in the DOM when moving them between columns. But you'd want to do this anyway with grid-lanes too, to make sure DOM order matches visual order. - You could also do this with flexbox, also by using wrapping column divs. - Finally, you could also just do this with absolute positioning, or floats. You have choice with CSS. For this simple demo, grid-lanes is a great fit because it gives us the flexibility of column definition. like grid.

Testimonials are a great use case for grid-lanes. These ones here are from Kevin Powell's CSS course website. Which, by the way, you should totally check out if you haven't. Kevin implemented this with multi-column, which is great, and perfectly valid. There's no one right answer, here the order of content isn't super important. Grid-lanes can do this very easily too, but the order's going to be different than multicol. Again, multicolumn fills columns entirely before moving to the next, whereas grid-lanes fills them one by one. The implication here is that you might be pulling these quotes from a database, and you might want to always see the latest ones first, near the top. Grid-lanes would give you this for free.

This sample shows the 2 different directions for grid-lanes, and lets users switch between them. Again, just using grid-template-rows or grid-template-columns is enough to tell the browser which orientation you want.

This sample illustrates the ability to have lanes of different sizes. Either all the same size, or first and last narrower, or alternating narrow and wide, or even following the Fibonacci sequence.

And this sample shows lane placement. The title here are placed in the first lane, and spans across 3 lanes. While masonry can seem chaotic, you still have control over the design.

Another example, showing the nice visual result of a dense masonry layout. And the ability to make some items span multiple lanes.

Using both bottom up and top down grid lane filling to create two photo strips. Combined with view transitions for a nice lightbox effect.

News sites like to densily pack content, in multiple columns, and grid-lanes is perfect for this. Here some articles span 2 lanes. And the ad in the middle spans all the lanes.

Generally, grid-lanes is a great tool for getting creative. This example shows a reverse gallery, where photos stack upwards, and then gradually disappear as you scroll down. And then you see them again at the bottom.

Another example with artwork search results, where the order of items is less important than the general visual result, and where space is optimized by filling gaps. Also great for loading more results at the bottom, like we saw before.

One more, this time to show the a row orientation grid-lanes layout. Each team here is a separate lane, and items are assigned to specific lanes. Certain tasks, like sprint planning span all lanes. What's cool about this one is how these spanning tasks end up pushing or pulling other tasks. If I make a task from team A longer, it ends up pushing the sprint planning, resulting in a planning change for all teams. Conversely, if I remove tasks from team B, the sprint planning can happen sooner. Same if I delete the sprint planning task, tasks for all teams can be scheduled sooner. Grid-lanes does this balancing act on its own, simply by its very nature of trying to fill lanes.

Grid Lanes doesn't always have to look like masonry. Again, it's great at occupying space, and you can put this to your advantage to create something something a little more unstructured, less rigid than a grid, more like something you'd actually create yourself, in real life.

Final one, very organic and creative, showing how much different than a typical masonry you can make grid lanes look.

Let's summarize on grid-lanes: (Click to reveal each box) High-level: - It's not just Pinterest in CSS. - It can be very creative and lead to new layout possibilities. Key points: - It inherits the power of grid's track sizing, for lanes. - But it's fundamentally 1D, lane-based. You don't get to control the other dimension. - Placement is opportunistic. Excellent for visual density. - But, you can still make strong design decisions with DOM order, lane assignment and flow-tolerance. - You can use it as aprogressive enhancement today.

That's all friends! Remember to have fun with the web. Entertain your inner kid. Go play. And push the web forward. Thank you.