CSS Grid Lanes
Key topics
The web is abuzz with excitement over CSS Grid Lanes, a potential game-changer for masonry layouts that have long relied on JavaScript hacks. Commenters are thrilled about the prospect of ditching cumbersome workarounds, with some sharing their own creative CSS grid solutions and others pondering the implications of adopting this new feature. As the discussion unfolds, a debate emerges around the trade-offs between supporting older browsers and embracing the latest advancements, with some arguing that the web should continue to evolve and others advocating for a more measured approach. Meanwhile, a broader conversation about the pace of change in web development is sparked, with some commenters drawing parallels to the evolution of programming languages like Python.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
16m
Peak period
117
0-12h
Avg / period
26.7
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 19, 2025 at 5:13 PM EST
21 days ago
Step 01 - 02First comment
Dec 19, 2025 at 5:29 PM EST
16m after posting
Step 02 - 03Peak activity
117 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 26, 2025 at 7:47 AM EST
15 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Thank you to everyone who is making this happen.
Adding a new element still need dimension of the element and a bit JavaScript. But resizing can be handled by css naturally.
https://codepen.io/zardoz89/pen/KKVEGbw
Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).
At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too? But they seem not to.
For example, the demo page linked in the article fails pretty unusably for me. All the images take up nearly the full viewport width.
How do you expect things to ever change if no one ever updates? Certainly even if you decide to lean towards maximum support it’s still a positive these features are being introduced so you can use them in 10 years.
Maybe things should stop changing.
We don't really need ten new CSS attributes every year. Things work. The elegant solution is to announce the project is done. That would bring some much-needed stability. Then we can focus on keeping things working.
Developers deserve nice things.
I agree they do. But Python is a bad counterexample. You can upgrade your Python on your server and no one has to know about it. But if you want to use new CSS features, then every browser has to implement that feature and every user has to upgrade their browser.
The intent of my comment was to express a desire to stabilize the web API in particular, not to freeze all software development in its tracks.
People get new browser versions for free, there are more important things to thing about than users that for some reason don‘t want to upgrade. Like I would rather have my layout done quickly with nice elegant code (and no hacks) and spend my extra time developing an excellent UX for my users that rely on assistive technology.
I digress.
I doubt this is going to happen as long as backwards compatibility continues to be W3C's north star. That's why all current browsers can still render the first website created by TBL in 1989.
Sure, official support for certain extensions should happen but HTML/CSS will always be at the core.
There are two kinds of technologies: those that change to meet user needs, and those that have decided to start dying and being replaced by technologies that change to meet user needs.
> If enough consumers aren't able to use the website, then business wouldn't use it.
I sincerely doubt any business owner would approve of losing even 10% of their potential users/customers if they knew that was the trade-off for their web developer choosing to use this feature, but there are disconnects in communication about these kinds of things -- if the web developer even knows about compatibility issues themselves, which you would expect from any competent web developer, but there are a whole lot of incompetent web developers in the wild who won't even think about things like this.
But your GP is in a massive minority, if every developer would cater to 11 year old browsers we would be wasting a lot of developer time to inferior designs, with more hacks which brake the web for even more users.
I'm not finding anything to corroborate that -- I'm seeing stats suggesting things like 90% of Chrome users are on the newest version after two weeks:
https://timotijhof.net/posts/2023/browser-adoption/
And Stat Counter shows that the current version of Chrome utterly dominates in any given month:
https://gs.statcounter.com/browser-version-market-share/desk...
I was specifically referencing desktop Chrome rather than Chrome for Android, but other than that, if there are discrepancies, I'm not sure what the cause is.
The Timo Tijhof data is based on Wikipedia visits, and shouldn't be affected by adblockers.
Meanwhile, StatCounter is based on sites that use its analytics, and on users not using adblockers that might block it. The CanIUse table makes clear there's a long tail of outdated Chrome versions that each individually have tiny usage, but they seem to add up.
It's fascinating they're so wildly different. I'm inclined to think Wikipedia, being the #9 site on the web [1], is going to produce a more accurate distribution or users. I can't help but wonder if StatCounter is used by a ton of relatively low-traffic sites, and the long tail of outdated Chrome is actually headless Chrome crawlers, and so they make up a large proportion relative to actual user traffic? Since they're not pushed to update, the way consumers are.
[1] https://en.wikipedia.org/wiki/List_of_most-visited_websites
Your position sounds reasonable upon elaboration, I only wish more web developers had the same consideration.
It doesn't even take many things to do this — the knock-on support of a bug in a driver that no-one wants to fix, a package that you like that prevents you from upgrading your host OS, web browser developers abandoning something about your GUI (how long before they drop X?) etc.
In the Linux world, the age of your machine is a limit with a blurry edge, but it's still there.
I don't think the world needs to cater to people that refuse even basic internet hygiene.
You want to platform to be able to make progress and not be frozen in amber by what we had at some "magical" year when things were in some Golidlocks powerful enough but not too complex state. Especially since a lot of progress lately has been fixing long-standing inconsistencies and obvious gaps.
The cost of that is that yes, neither my Apple IIe or my Micro Pentium 90 run the modern web... one day my MBP M1 won't either.
So what OS are you running that can't run modern versions of browsers, and on what hardware?
Current Chrome runs on Windows 10, which came out 9.5 years ago but was intended to run on older computers, and macOS Monterey, which runs on Macs from ~2014-2015 depending on the model. But even Big Sur before that, the most recent version of Chrome which runs on that is Chrome 138 from just 6 months ago, and that doesn't seem old enough that you need to build userscript hacks.
I'm really curious what you're actually running. Generally speaking, an 11-year-old machine should be able to run the current browser, and if not, a very recent one.
Yes. I held off learning about CSS Grid for a very long time and as soon as I did I was converted. Sometimes I think the web doesn’t get enough credit for its ambition: mobile viewports, desktop viewports, touch interaction, pointer interaction… it’s a lot. But you get some complexity as a side effect.
If you’ve been at this for a while, it’s important to remember that browsers update a lot faster than they used to. Anchor positioning came out last year, for example, and all of the major browsers support it by now. Very old devices are a problem but security is purging those out faster than used to be the case.
We also have better tools for progressive adoption since you can easily query for things like CSS feature support. In this demo, they didn’t implement fallbacks but in most real sites you’d have something like a basic grid layout which is perfectly serviceable for the fraction of users on old Firefox releases.
The version of CSS Grid we're using today didn't ship until 2017; a browser from 11 years ago would be using one of the non-standard versions of Grid. For example, Internet Explorer 11 was the first browser to ship a grid implementation.
> At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too?
First, not every site needs to look exactly the same in every browser; that's why progressive enhancement is a thing.
Second, there are multiple ways to create masonry-style layouts that don't require masonry support in the browser using multi-column layout or flexbox.
Third, masonry can be polyfilled using JavaScript [1].
[1]: https://masonry.desandro.com/
Certainly can: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
https://m.youtube.com/watch?v=yikbSQ6tvlE
https://github.com/w3c/csswg-drafts/issues/10233
Masonry or grid-lanes, who cares? I’m just glad masonry (the feature) and subgrid are finally here.
I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.
> Help us invent CSS Grid Level 3, aka “Masonry” layout
> P.S. About the name
> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.
— https://webkit.org/blog/15269/help-us-invent-masonry-layouts...
> Help us choose the final syntax for Masonry in CSS
> We also believe that the value masonry should be renamed.
> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.
> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).
— https://webkit.org/blog/16026/css-masonry-syntax/#footnote-1
> [css-grid-3] Renaming masonry keyword
— https://github.com/w3c/csswg-drafts/issues/9733
Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.
It got to the point where I believed that subgrid was dead. FF implemented it but absolutely no one else did, for years.
Is it our fault for tuning out of the debate? Yep. But tactics were employed to achieve that exact outcome. I'm fine admitting that I tuned out. But it was a battle of attrition waged by people who were fine holding up progress indefinitely.
Is that how you want decisions to be made?
Ultimately I'm not too concerned what you call the masonry feature. However the debate over what to call it was an extreme case of bikeshedding. I would have rather given up the fight over semantics to resolve the non-issues and ship the feature years ago. As it stands we're still years away from actually being able to use the feature in production.
I've stopped waiting for companies, committees, or projects to change course. I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Why bother? I have an incentive to spend my time building features that users will use.
There’s no incentive to the companies or the employees to draw out the discussion, especially over something so trivial. It’s much more preferable to try and speed through things to get things done in a time frame that can be adopted.
And regardless, if you don’t feel it’s worth your time, then why cast aspersions that it was something clandestine and intentionally hidden? You could have shown up and kept up with it, just like everyone else involved presumably did.
I didn’t ascribe a motive to anyone. Their reasons are their own and it only makes sense that the people who stay in these fights do it because it’s part of their jobs.
There are people who, for whatever reason, keep debates going over small points of disagreement and prevent issues from being settled. Sometimes for years. Right?
The older I get, the more likely I am to recognize and route around or ignore interminable debates. Especially if it’s not for a company, project, or initiative under my direct control.
Remember, the question at the top of this thread was essentially “What happened to ‘masonry’?” Well, there were quibbles over the descriptors.
I don’t care about quibbles. Masonry, grid-lanes, pick one, they’re equivalent. I don’t like it when quibbles block progress.
Sometimes people and companies do want to hold things up. Like I said earlier:
> I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist.
Pick your battles.
I don’t think the masonry fight was worth it. It should have been settled and implemented years ago.
It sucks whenever browsers backtrack on a W3C standard that reached "Working Draft" status but it doesn't seem like it's gonna impact many people
Besides, it's not being "deprecated". It will continue to work as it does. We just have a better alternative that the big 3 all agreed on.
This will of course slightly crop all your images to make it fit, but in practice as long as you keep your image aspect ratios reasonable and the images small enough on the page it's really quite subtle.
I had hoped that this feature would provide for masonry like that, but one has to make do.
Browsers supporting the new syntax will override the `display: grid` with `display: grid-lanes` and ignore the `grid-template-rows: masonry` syntax.
You should tune out more of the ambient cynicism because it's unhinged and grounded in ignorance. People who don't follow the standards discussions, don't talk to web devs, don't read anything except headlines and try to fit in with whatever cynical, depressed social media bubble they ended up in.
https://wpt.fyi/interop-2025
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
I think they realized that shipping the features out of sync meant nobody could use them until all browsers adopted them, which took years, so now they coordinate
I can't think of a single good reason why they don't adopt an "evergreen" 4/6-week update model except Not Invented Here syndrome or "it's not Apple-like, we prefer the OS team (and therefore Marketing) dictating our release schedule, users be damned".
It's an own-goal for no reason.
I recognise that this is a controversial take, but in my opinion what Google is doing is a variant of “embrace and extend”. Traditionally, this meant proprietary extensions (e.g. VBScript) but I think it should also apply in this case too.
The ever current adage of distortion field applies here.
Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature. Apple can do no wrong to some. Whatever they do is a feature. And if they don't do, it's a feature too.
Implying otherwise is itself a bad argument.
It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are a few narrow instances where Safari had an incomplete or broken feature implementation. But many claims of “broken sites” are really just evidence of lazy developers failing to test beyond Chrome or to implement graceful fallback. Relying on bleeding-edge Chromium features before they've been broadly adopted by browsers is, IMHO, a infatuation with novelty over durability. It's also, IMHO, a callous disregard for the open web platform in favour of The Chrome Platform. Web developers are free to do whatever they like, but it's misleading to blame other browsers for the predictable outcome of their choice.
Correct. People test Chrome first and often only. That'll never change because people are lazy and you have a humongously long tail of websites with varying levels of giving a shit and no central authority that can enforce any standards. Even if another browser takes other, they'll only test that one.
The solution is formal tests and the wpt.fyi project. It gives a path to perfectly compatible implementations of agreed-upon standards, and a future where *the only* differences between browsers will be deliberate (e.g. WebMIDI). Brilliant.
That's why I wish the gap between Safari TP's wpt.fyi score and Safari stable's score was shorter. Simple!
That hasn't been true for a few years now.
Even now, when a site breaks in Safari, more often than not, it's because that particular site is using a Chrome-only feature that hasn't shipped in Safari or Firefox yet. These developers need to be reminded that progressive enhancement is a thing.
There are web developers who only test their sites on Chrome, which makes no sense, given mobile Safari has around 50% marketshare in the US [1] and about 21% globally [2].
> Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature.
I must have missed this one, but anyone paying attention would have noticed WebGPU had been available in Safari (behind a flag) long before it became official; it was always on track to becoming a real feature.
[1]: https://gs.statcounter.com/browser-market-share/mobile/unite...
[2]: https://gs.statcounter.com/browser-market-share/mobile/world...
You shouldn't be allowed to use an old device with an updated browser, especially not a browser from a 3rd party, because that doesn't help Apple sell more iPads.
There's a new version of Safari Technology Preview [1] for macOS every two weeks.
There's a new version of Safari released every September for macOS, iOS, iPadOS, and visionOS. This has been the schedule for several years. Since Safari 26 shipped on September 15, 2025, there have been two updates for these platforms:
Safari 26.1 on November 3rd and 26.2 on December 12th.
The Safari team shipped 7 releases this year, averaging 7½ weeks between releases; not a significant difference from 4–6 weeks. Each major release of Safari for macOS runs on the current macOS version (Tahoe) and the two preceding ones—Sequoia and Sonoma.
BTW, there were 9 Safari releases in 2024, averaging 5.8 weeks apart.
At the end of the day, there's no NIH or Marketing team dictating the release schedule.
[1]: https://webkit.org/downloads/
I use Safari as my default, and like every Firefox/Safari user I still get some bugs that don't occur in Chrome (not talking about WebMIDI obviously), so watching that 30 point gap between stable Safari and bleeding-edge WebKit (longer than 7½ weeks) on wpt.fyi was quite frustrating. The average Safari user would have a better browsing experience with a shorter fix delay, that's just the truth. Having to wait for macOS updates holds back the browser, unnecessarily.
Safari is an operating system component, which lots of people don't seem to understand; hundreds of thousands of 3rd party apps rely on Safari's WebKit engine.
I've never heard a normie Safari user complain that Safari updates aren't being released quickly enough; that's something web and app developers care about… which is why Safari Technical Preview is released every two weeks.
Even the release versions of Safari on iOS, iPadOS and macOS allow you to enable web features that are still in development.
https://github.com/web-platform-tests/interop/issues/1121
https://webassembly.org/features/
https://wpt.fyi/results/wasm/jsapi?label=experimental&label=...
The full test-suite of wasm tests are here:
https://wpt.fyi/results/wasm
https://wpt.fyi/results/?label=master&product=chrome&product...
To answer your question, yes. Apple requires 80% test passage of all the tests on web-platforms-test in order to be considered as a valid browser for iOS so they specifically targeted this suite to reach that milestone
It's a pretty silly requirement because wpt is not really meant to be representative of all web platform standards. It includes tests for non-standard features and the majority of tests are simple unicode glyph rendering tests.
Apple is fighting it tooth and nail and coming up with requirements for other engines is a small way of doing that.
Their result is: 1974740 / 2152733 (91%)
They also have their own dashboards tracking this [2]
[1] https://wpt.fyi/results/?product=ladybird
[2] https://grafana.app.ladybird.org/public-dashboards/2365098a1...
It's good they're trying to not make Safari suck as much.
Caniuse is pointless, their new "baseline" score is pointless; as long as enough people keep using their (perfectly fine and working) iPhones after official support stops and as long as they are not allowed to install a different browser (engine), that's the only data point you need to look at when choosing which browser features to use.
One could argue Safari on iOS being like macOS where it could be updated standalone, but current rate isn't too bad.
Absolutely true! I've said the same thing many times myself.
Stating that Safari is the new IE is one of the answers to:
"Tell me you didn't do web development in '90s and have no idea what you're talking about without telling me you didn't do web development in '90s and have no idea what you're talking about."
Also the thing is that there are plenty of features supported by Safari and Firefox that Chrome is slacking on. Nobody every complains about those features though because nobody would try to use a feature not supported by Chrome in the first place
Of course Safari pushes to have anything they don't want to support not in that subset.
Hopefully they will make Safari smoother and faster with Multi Tabs in future release. There are lots of multi tab feature they could copy from Firefox.
Not all of us were surprised; some of us have been watching the Safari team shipping the latest HTML and CSS features for a few years now.
The other posters have good answers. One thing to consider for a smooth interaction would be to eagerly load the next x elements before they scroll into view.
If you try to go left-to-right, you will quickly realize that at the end of each "line" it is really difficult to know where the next line starts. It is easy to accidentally start again on the same line (and inspect the same elements), or skip one accidentally. Then navigating through the elements one by one requires a considerable amount of cognitive effort, your eyes bounce up and down constantly, and you end up inspecting the same elements multiple times.
If you try to go top-to-bottom, lane by lane, you will then realize that the page also has infinite scroll and you will never go past the first lane.
Larger images dominate and flashy images become more important to get attention (if bringing focus to an image is the idea). An extremely poor way to present information.
Chromium still seems to be working on support it seems based on https://cr-status.appspot.com/feature/5149560434589696 so maybe it'll be useful soon? That page indicates that they're still discussing certain parts of the spec.
Masonry works well if you have different aspect ratios of the same orientation.
Here is an example of the layout of a photostream that I was satisfied with.
https://frifoto.emilbratt.no/?view_mode=photo-stream&tag=All...
The defining feature of masonry is that it supports mixed aspect ratios. That's its whole thing. If you aren't mixing landscape and portrait images, you shouldn't be using masonry layout.
If you force all images into a uniform aspect resolution, they get squashed and stretched and look terrible.
If you make the images full resolution, there will be huge swathes of empty space in between them because they don't pack tightly.
Masonry layouts allow you to preserve aspect resolution without wasting a massive portion of your user's screen space. It's not perfect, but it's the best solution to mixed aspect ratios that I know of.
If you know of a better method to handle mixed aspect resolutions, I'd love to hear it and would gladly rescind by remarks.
Consider a similar layout to OP but the landscape images will span multiple columns as well as everything it already does.
The thing about masonry is that it adapts to the size of the images. You could already do masonry using flexbox if you know the image sizes (https://github.com/hannasm/masonflexjs). Doing it as a true mosaic layout would be a step above current capabilities. At that point it's probably pretty easy to create configurations that don't fit perfectly/ require lots of empty space to layout nicely though.
[1]https://safebooru.donmai.us/ (note: this is a "safe" subset of danbooru for reference, but it is still not safe for work)
Actually that's exactly what they do. They like the animations while some people, especially devs, do not. But they don't use it multiple times, because they would be able to see how it gets annoying after the first time.
One of the biggest arguments over the last couple of years was what to call it. A lot, lot of ideas put forth as alternatives to "masonry" which wasn't thought to be great for non-English speakers. I'm glad they finally nailed a name for it!
The other big argument was over how to activate it. Is it a grid? Is it a flexbox? Is it a brand new animal?
Now I just need to figure out the best way to implement this semantically with a polyfill for the next 30 months until it's baseline.
I don't think the smooth reflow made it into the current spec, so I guess watch this space?
https://www.w3.org/TR/css-grid-3/
65 more comments available on Hacker News