Hacker News Reader

Comment by culi | Hacker News Reader

Props to the Safari team. They surprised us all when they suddenly shot to the top of interop-2025 this October

https://wpt.fyi/interop-2025

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!

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

I thought that was supposed to be fixed by contenteditable plaintext-only. Why was field sizing still necessary?

`contenteditable` is an HTML attribute but it depends on JavaScript to do anything useful. This problem is one of layout, CSS's domain, so `field-sizing` solves it while leaving HTML form elements to do the actual job of taking input.

At least recreate their demo for us to showcase the fix. But I feel like it would be a let down that answers your question.

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".

It's an own-goal for no reason.

The web platform doesn’t need to move this fast. Google is, often unilaterally, pushing new features and declaring them standards. In my opinion, the web should not be changing so fast that a truly open source community project couldn’t keep up. I don’t like how the web has become reliant on the largesse of billion dollar corporations.

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 this a subtle variant with similar consequences.

I know it's fashionable to forcefully shove the same pet peeves about Chromium into any topic even loosely related, but here I'm talking about Safari webcompat fixes, bug fixes, and improvements having very long delays between being written and landing in customers' hands. I would make the same argument if Chrome never existed. Thank you for presenting the 10,001st reissue of this "controversial take".

The behaviour of entities that WebKit is ostensibly told to be compatible with isn't a "loosely related" topic, it's precisely on-point. It's certainly no less on-point than nebulous criticisms of Apple for assumed NIH syndrome or marketing priorities. You criticise Apple for not having a rapid release schedule; I am criticising the very notion of rapid release schedules (other than security patches).

The web platform doesn't need to move so fast.

How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing?

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.

I agree that numerous companies inspire occasional weird reflexive defences from their most enthusiastic supporters. Thankfully, bad arguments have no transitive value.

Implying otherwise is itself a bad argument.

It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. 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 browsers for the bad choices and/or laziness of some web developers.

> But many claims of “broken sites” are really just evidence of lazy developers failing to test beyond Chrome or to implement graceful fallback.

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!

Why do you keep conflating bug fixes with new platform features?

Because such bugs were predominantly associated with then-new platform features.

As a web developer myself, I appreciate the frustration with Safari's flexbox bugs of a decade ago and viewport bugs more recently. I also remember being endlessly frustrated by Chrome bugs too, like maddening scroll anchoring behaviours, subpixel rounding inconsistencies, and position:fixed bugs which were broken for so long than the bugs became the de-facto standard which other browsers had to implement. All browsers have bugs. To suggest that Safari was uniquely bad is to view history with Chrome-tinted glasses.

I'm not saying that other browsers don't have bugs. This thread is about how Safari doesn't fix them for a long time because it ships slowly.

You are assuming that Safari didn’t fix bugs for a long time because it “ships slowly.” Maybe some bugs are just complicated and take time to fix. It took Google years to fix the bugs I mentioned earlier (and many others) despite having the largest budget of any browser project and a VERY rapid release cadence.

No a lot of them are pretty straightforward, this is why I’m upset. I’m talking about, like, “SVGs with this feature don’t render correctly due to an oversight in size calculation” not “can you please implement WebGPU in the next release cycle”.

> How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing?

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...

"Google learned from Microsoft’s mistakes and follows a novel embrace, extend, and extinguish strategy by breaking the web and stomping on the bits. Who cares if it breaks as long as we go forward." https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

That's a good article. Thanks for surfacing.

VBScript is a word I hadn't heard in quite a while! Brings back memories of editing 5k line .asp files to find an if statement and then a 1000 lines of html and such. Sadly, I dont' think web development is actual better 20+ years later, just different...

The web platform on your device needs to be locked to a specific version because the OS stopped being updated. Once the OS stops being updated, you're supposed to buy a new device.

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.

> 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".

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.

It's not the first time Safari shipped a significant new feature before other browsers; :has(), Display P3 color support, JPEG-XL come to mind. At the end of the day, there's no NIH or Marketing team dictating the release schedule.

[1]: https://webkit.org/downloads/

The Safari/WebKit people are doing good work, yes.

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.

> 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.

The bugs aren’t necessarily the browsers fault.

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.

> They surprised us all when they suddenly shot to the top of interop-2025 this October

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.

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".

https://webassembly.org/features/

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:

https://wpt.fyi/results/wasm/jsapi?label=experimental&label=...

The full test-suite of wasm tests are here:

https://wpt.fyi/results/wasm

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

All of the above and even more so to have those features behave identically across the member browsers.

Nice Chart. This along with Interop 2024 actually tacks well what I thought was major improvements. I first noticed it was Safari 18 and Safari 18.2, and then Safari 26 and now 26.2 where sites that dont used to work well are now all working. To the point for as long as Safari 26.2 has released I dont remember I had to switch to Chrome or Firefox to check. Where previously I do it at least monthly or quarterly.

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.

Safari became the new IE for a while, the amount of problems I've had with Safari CSS animations and SVGs is endless.

It's good they're trying to not make Safari suck as much.

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.

iPhone or iOS has the highest upgrade percentage of OS. ~85%+ are on iOS 18 or higher. Liquid Glass iOS is the first time update has been slower. But Apple generally achieve near or over 80% of latest iOS by end of its cycle i.e coming August / September.

One could argue Safari on iOS being like macOS where it could be updated standalone, but current rate isn't too bad.

The only people who think Safari is the new IE are people who weren’t around for IE.

it's also not possible for Safari to be the new IE because they don't have 95% marketshare. And IE's unique problem was that they pushed features that only they supported. Safari's problem is it doesn't support certain features

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

> The only people who think Safari is the new IE are people who weren’t around for IE.

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."

I hope they add WebTransport support soon.

voting for interop 2026 is active now. I see somebody has already submitted a proposal for it

https://github.com/web-platform-tests/interop/issues/1121

My favorite is finally supporting `arbitrary-subdomain.localhost`. Been a real pain in the neck to add Safari-specific fallbacks for my usage of that.

Oh, that's nice for sure! Has it been announced anywhere?

Does it still expand an svg to full size if u omit width and height attributes because u control the size in a parent container? Fuck safari

I wonder if Ladybird has explored running these interop tests yet. Or maybe these are just a subset of WPT?

You can edit the "products" represented in the table and add "Ladybird" to the list. [1]

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...

Here's a comparison including the big 3, ladybird, servo, and flow

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.

I thought that no other browser engine could be provided on iOS. so no ladybird's engine, no servo, no gecko, no blink, only webkit

Some geographic regions have declared that not allowing other OS engines on iOS is anticompetitive so they're requiring Apple to allow them.

Apple is fighting it tooth and nail and coming up with requirements for other engines is a small way of doing that.

that was true until a few months ago due to a ruling in the EU. It's still currently the case that only WebKit can run on iOS but they're gearing up to change that

They are indeed just a subset of WPT. Although the way subtests are weighted in the score calcustion is slightly different for the "interop" score.

interop-2025. It does not mean Safari supports all the latest stuff. It means, "for some small subset of stuff here's the percent that's supported".

Of course Safari pushes to have anything they don't want to support not in that subset.

Reply on news.ycombinator.com