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 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.
Cool stuff they're working on tends to take a very long time to reach customers' hands compared to other browsers. Just compare the "stable" and "experimental" graphs on wpt.fyi for Safari.
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".
Safari has been releasing a lot more often than it used to. My personal gripe with Safari is how they decided to deal with extensions, forcing every developer through their hellish App Store submission experience.
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.
Imagine if the literal army of Chromium/Blink engineers threw their entire weight into making the fundamental building blocks that everybody uses better instead of niche things that only a tiny fraction sites and web apps will ever need.
Hm, I know that Safari doesn't support 64bit wasm, which is a very important feature that Chrome and Firefox both have, but this seems to say they have "100% webassembly support".
interop is a subset of tests chosen beforehand (nowadays, mostly by devs voting in the github issues). This says Safari has reached 100% on the subset of tests agreed upon for interop-25. Those specific tests can be expanded by clicking it in the menu. It'll take you here:
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
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.
Safari is still the new IE. Well, not really "new", it has been IE all along. It's the only non-evergreen browser that remains, and I don't get why this isn't mentioned every time Safari is brought up. All of their spec implementations are meaningless when the only version that matters is the one forever stuck in whichever oldest iPhone n% of people still use.
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.
It is funny how we keep asking more and more and more even though we already have it so much better than before. Can we never be happy with what we have?
> It is funny how we keep asking more and more and more even though we already have it so much better than before.
I've been developing web stuff for 15 years now and sometimes I can't believe comments like these. We didn't have it "so much better before". CSS sucked hard and getting things right for three devices was an incredible pain in the ass.
Tables have semantic meaning. They don't support fractional units. Reflowing for mobile is impossible and you need JS hacks like splitting tables. You can't reorder natively.
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.
Adding a new element still need dimension of the element and a bit JavaScript.(The whole page use < 100loc unobfuscated JavaScript) But resizing can be handled by css naturally.
I think the issue here is most people don't really have a good way to specify how masonry should work. And thus don't have a good implementation either.
There is an element of tragic comedy to those announcement. While remarkable on their own, everybody knows that one cannot use any new browser feature reliably any time soon due to Apple not shipping continuous updates to the browsers they force upon their users.
I know one of my clients complained something didnt work on their few year old iPad. So.. I don't know what the cutoff is but clearly not everything updates regularly. He did try updating it manually too but couldn't.
A lot of web "design" is about how it looks rather than how usable it is. At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl". Never mind the text that is at 50% opacity until you scroll to the exact intended point, because nobody actually attempted to read it.
> At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl".
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.
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.
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.
But if you don't need to systematically examine every element one-by-one, lane layouts are pretty good. Sites like Pintrest use lane layouts because their content isn't meant to by systematically examined, but rather absorbed at a glance. If your content is meant to be systematically examined, using a lane layout would be a bad UX choice. But just because lane layouts can be misused doesn't mean they're a bad layout.
IMO it's annoying to use at all. It just looks "good" (subjective).
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.
It's not meant to be "efficient," it's meant to allow your eyes to look at the entire page at once to find what you're looking for. A newspaper or photo gallery comes to mind.
(Not GP poster.) I don't really have a problem with masonry layouts, but a newspaper is limited by the paper size and they have incentive to squeeze everything in there (to maximize the spread of "information"). The screen is theoretically infinite (although not for kiosks).
I do have a website with a lot of images, and at the moment everything is in a 3-across grid layout...
After reading the top-left block of text titled "Optimizing Webkit & Safari for Spedometer 3.0", what the fuck am I supposed to read next? Am I meant to go recursively column by column, or try to scrutinize pixels to determine which of the blocks are further up than the others, skipping haphazardly left and right across the page? A visual aid: https://imgur.com/a/0wHMmBG
Columnar layout is FUNDAMENTALLY BROKEN on media that doesn't have two fixed-size axes. Web layouts leave one axis free to expand as far as necessary to fit the content, so there is no sane algorithm for laying out arbitrary content this way. Either you end up with items ordered confusingly, or you end up having to scroll up and down repeatedly across the whole damn page, which can be arbitrarily long. Either option is terrible. Don't even get me started on how poorly this interacts with "infinite scroll".
I agree, this seems to violate some of the most fundamental concepts of design like least-surprise and using grouping + alignment to give context to readers.
I'm pleased they rename it because grid-lanes opens up more than masonry layouts.
I've been waiting to be able to have a fully responsive layout (where interleave sidebar content in with the page content on small screens, but have it in a sidebar on larger screens) without using any JavaScript, and this finally makes it possible.
The naming was half the discussion on implementing this. There were a lot of people smarter and more knowledgeable than me that had a lot of opinions on the name that I hadn't thought about. I remember one of the reasons was that the word "masonry" wasn't as obvious a concept for non-English speakers.
https://wpt.fyi/interop-2025
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
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.
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.
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
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
https://github.com/web-platform-tests/interop/issues/1121
Of course Safari pushes to have anything they don't want to support not in that subset.
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...
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.
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.
I'm tired of having to use stupid hacks to get nice-looking borders between flex/grid items.
It is funny how we keep asking more and more and more even though we already have it so much better than before. Can we never be happy with what we have?
I've been developing web stuff for 15 years now and sometimes I can't believe comments like these. We didn't have it "so much better before". CSS sucked hard and getting things right for three devices was an incredible pain in the ass.
Tables have semantic meaning. They don't support fractional units. Reflowing for mobile is impossible and you need JS hacks like splitting tables. You can't reorder natively.
Thank you to everyone who is making this happen.
Adding a new element still need dimension of the element and a bit JavaScript.(The whole page use < 100loc unobfuscated JavaScript) But resizing can be handled by css naturally.
I think the issue here is most people don't really have a good way to specify how masonry should work. And thus don't have a good implementation either.
I can't check because my wife's iPhone is, regrettably according to her, "updated to the latest glAss version".
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.
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 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.
I do have a website with a lot of images, and at the moment everything is in a 3-across grid layout...
After reading the top-left block of text titled "Optimizing Webkit & Safari for Spedometer 3.0", what the fuck am I supposed to read next? Am I meant to go recursively column by column, or try to scrutinize pixels to determine which of the blocks are further up than the others, skipping haphazardly left and right across the page? A visual aid: https://imgur.com/a/0wHMmBG
Columnar layout is FUNDAMENTALLY BROKEN on media that doesn't have two fixed-size axes. Web layouts leave one axis free to expand as far as necessary to fit the content, so there is no sane algorithm for laying out arbitrary content this way. Either you end up with items ordered confusingly, or you end up having to scroll up and down repeatedly across the whole damn page, which can be arbitrarily long. Either option is terrible. Don't even get me started on how poorly this interacts with "infinite scroll".
Deleted Comment
I've been waiting to be able to have a fully responsive layout (where interleave sidebar content in with the page content on small screens, but have it in a sidebar on larger screens) without using any JavaScript, and this finally makes it possible.
Demo: https://codepen.io/pbowyer/pen/raLBVaV
Previous comment: https://news.ycombinator.com/item?id=46228993