I didn't realize it was tracked like this, but I have noticed that as of iOS 26, Safari has gotten a huge number of great web features. It has WebGPU of course, but many small things like fixing up missing parts of the OPFS API that make it actually usable now. Now they even have the field-sizing CSS property [0], fixing imo the most glaring ommission from CSS: the inability to make text input boxes grow to fit the input text!
This is not all that surprising. While the Chrome team is out there evangelising things like WebPCIe or whatever, Safari's been shipping features clients actually want, like blurred backgrounds for years before anyone else.
This seems like a bit of a trend with Safari. Around big releases Apple will announce how Safari is the best at X, but other times of the year it gets a lot of flack. I assume this is due to Safari’s more traditional release schedule vs other browsers continuously shipping feature updates.
Fascinating tracker. So we started 2025 with nearly every browser under 80% and ending the year with every browser with >98% interop? That's a lot of amazing work done by a lot of teams. Incredible!
Just to clarify the meaning of the measurement, it doesn't mean they're 98% interoperable across everything, it's across the specific set of goals for 2025. (Which is still really good!)
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 have to ask, like with all the other browser specific trial implementations: how is cross platform support? If we wanted to make a grid layout that only worked in one browser engine, grid-template-rows: masonry was there for a while now.
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.
This is exciting to see! I just used Masonry for a project this past week. While it works quite well and is pretty performant, it is pretty hacky using absolute positioning, wanting to know the aspect ratios of objects beforehand for smoother layout, and having to recalculate everything on resize. I'm looking forward to having a generally available native option one of these days.
Me, too. I like masonry layout too much to wait for CSS to solve the problem, so I've been waiting to remove the last 1.3KB of Javascript from my home page since 2019.
I have often thought layouts should be done by a constraint solver. Then there could be libraries that help simplify specifying a layout, which feed constraints to the solver.
I've done that for desktop apps before. You have to be careful with the effects of sub-pixel rendering and whatnot if your math is continuous, but it's a viable path that I quite like.
Maybe this will be an unpopular opinion, but I really dislike the lane layout, because it is not possible to efficiently take a glance at all elements in the list, one by one.
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.
Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”
Masonry was never “in”, no? Mozilla proposed it and were the only ones to implement it, behind a feature flag. Then WebKit proposed an alternative that was discussed at length:
I still prefer the layout look from something like justifiedGallery.js where the heights of each row are the same. Actual masonry with stacking stones would never stack directly on top of each other like this. Calling it masonry just feels unnatural as anything stacked like that would easily be knocked over. "Lanes" is definitely more appropriately named than "masonry". The layout look of a justifiedGallery would be more masonry than the grid-template-rows:masonry setting. yeah yeah, raw css vs js library blah blah
I guess you can just start loading a first batch, add an intersection observer to the last 3 elements (if you have 3 lanes) and then when one of those intersects you simply start fetching the next.
Masonry grid layout was one of a few interviewing pair programming tests I would give to frontend engineers. I need to see how this works under the hood!
I don't understand all the busywork goes behind new browser updates, just to retain their market share (since they can afford more engineers, than say Ladybird). Is this needed? It's not rocket science, folks.
Psh, rocket science only has to contend with physics, which generally doesn't change much, if at all. The equations used to get humans to the moon didn't change because someone discovered you can send a specially crafted packet and escape the sandbox and steal money from everybody on the Internet.
Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
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.
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 desktop should be able to run the current browser, and if not, a very recent one.
> 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).
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].
> Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
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.
> Is this increasing complexity in the Web layout world worth it?
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, complex documents, webapps… it’s a lot. But you get some complexity as a side effect. The complexity we do see these days isn’t invented out of whole cloth, it’s standardising and improving layouts people are implementing with JavaScript, often badly.
When the web came out it itself was new technology that excluded some older machines. Lynx kind of worked (I used it!) but it was a poor substitute, especially once `<img>` showed up.
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.
Sooner or later, the age of your machine will affect browser compatibility.
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.
Not updating your browser will net you tons of exploitable vulnerabilities.
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.
> How do you expect things to ever change if no one ever updates?
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.
The issue with this is that the browser is the cross-playing operating system, the VM that runs webapps. But we treat the platform like an evolving document format. If we want to declare it complete, we need to make it extensible so we can have a stable core without freezing capabilities. I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes. WASM is one step in that direction. There are custom rendering/layout engines now, but they basically have to render to canvas and lose a lot of performance and platform integration. Proper official support for such engines with hooks into accessibility features and the like could close that gap. Of course, then you have every website shipping a while OS userland for every pageload, kinda like containers on servers, but that overhead could probably be mitigated with some caching of tagged dependencies. Then you have unscrupulous types who might use load timings to detect cache state for user profiling... I'm sure there's a better solution for that than just disabling cross-site caching...
> I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes.
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.
11 years ago we had Python 2.7.8 and 3.4.0 so no type hints, no async await, no match syntax, no formatted string literals, large number couldn’t be written like this 13_370_000_000, etc.
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.
If enough consumers aren't able to use the website, then business wouldn't use it. The reality is new computers aren't that expensive (I see used M1s for under 1k) and consumers are upgrading.
You mentioned a used model that is over 5 years old as an example of "a new computer", and "1k" as "not expensive for consumers". It is honestly impressive how well you undermined your own point.
> 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.
Most web devs get screemed at (by their peer reviewers or [preferably] static analysis tools) if they use a feature which has less then like 98% support without gracefully denigrating it, and rightfully so.
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 don't know about "most". For various reasons, I use a 2-year-old browser on a daily basis (alongside an up-to-date browser), and I routinely run into websites that are completely broken on the 2-year-old browser. Unrelated to outdatedness, I recently ran into a local government website that e-mailed me my password in plaintext upon account creation. I have no way of accurately quantifying whether "most" web developers fall into the competent or incompetent bucket, but regardless of which there are more of, there are a significant enough number of incompetent ones.
Yes it is. Developers write bad code when they try to work around the lack of features with ill thought out hacks, this results in a bad website for everybody, even those of us that keep our software up to date, and just so happen to have a different screen resolution and a different browser then what the developer tested on.
https://wpt.fyi/interop-2025
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
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.
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
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.
Thank you to everyone who is making this happen.
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.
grid-template-rows: masonry;
is going to be outdated then?
https://m.youtube.com/watch?v=yikbSQ6tvlE
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.
https://github.com/w3c/csswg-drafts/issues/10233
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.
I don't think the world needs to cater to people that refuse even basic internet hygiene.
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 desktop should be able to run the current browser, and if not, a very recent one.
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...
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.
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, complex documents, webapps… it’s a lot. But you get some complexity as a side effect. The complexity we do see these days isn’t invented out of whole cloth, it’s standardising and improving layouts people are implementing with JavaScript, often badly.
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.
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.
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.
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.
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.
> 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.