Sorry Safari Team | Hacker News Reader

Sorry Safari Team

paul.kinlan.me

207 pointstosh153 comments

I'm confused why Apple should get to compare the stuff in their Technology Preview, instead of the actual browser that people are using day to day. It took Apple eons to ship `navigator.getUserMedia`. This was a serious hindrance to those that wanted to provide a cross-browser video upload experience. Yet if we went by their Tech Preview, one would be able to argue that they supported it.

Apple if very frustrating in this way. They have a massive amount of resources, yet they choose not to put those resources into developing their browser. That's fine, that's their choice. But telling everyone that they support something that they only "intend to support at some future date" is less than honest.

If everything in the Tech preview gets to users 6 weeks later, as is the case with most Chrome features, I don't think it matters.

But the fact Tech Preview stuff sometimes stays unreleased for years makes it a different matter...

Agreed. In the article he mentions that it's only fair to include tech preview features because the chrome team gets to include canary features. However, there is a clear process from canary -> production that doesn't exist with safari tech preview.

In this case there Non-tech preview version of safari scored higher, due to a bug in the testing framework which was not correctly updating the tech preview version used.

Yet they still used the tech preview number which was much lower, in their slides

That's why there's uproar, chrome dev tools team showed the lower score which was caused by a non-updating test framework and people ran with it

> due to a bug in the testing framework

the "bug" is https://github.com/web-platform-tests/wpt/issues/31147

MacOS 11 isn't allowed(?) to be virtualized, so the Safari TP, which is tied to MacOS updates, couldn't be updated.

> That's why there's uproar

Was there an uproar? There were some objections from some Safari devs that they understood the difficulty in getting the latest number since the web platform test runner can't run the latest Safari Tech Preview (which they've also known for some time), but since the whole point of this was to show how browsers have improved their compatibility on this set of tests, it was hurtful and counterproductive to leave out their latest work. Chrome devs apologized and now we have this article, and it looks like the test runner will start running WebKitGTK for this set of tests so at least the Compat 2021 dashboard[1] will show the latest results.

[1] https://wpt.fyi/compat2021?feature=summary

> MacOS 11 isn't allowed(?) to be virtualized

IANAL, but IIIRC, MacOS isn't allowed to be virtualized on non-Apple hardware

Note that web-platform-tests has frequent runs of the included browsers in both nightly/dev/tech preview configurations and in stable configurations. And in all browsers there can be things which are enabled in these experimental builds which aren't going to ship in the next release. One can argue of course that it makes more sense to make all the comparisons on the basis of what's actually shipped to users, but that wouldn't have changed the story here.

All browsers got to be compared on their bleeding edge/canary builds for this, not just Safari.

Except that there's a very big gap between what's being actually shipped in each browser. Comparing Chrome edge with Firefox edge is okay since they have a similar release schedule, Safari is much much slower though.

I double checked on Wiki, it seems for the past 6 years Safari has been on a 6 months release cycle. Major version in September and minor release in March / April.

So this isn't as bad as I thought. The difference being previously their development speed have been very slow so it felt not doing enough. They picked up their progress since Safari 13 and are now catching up in lots of areas. You will notice Safari 15 TP release note is getting long with every release.

So may be in terms of webpage it is not that bad anymore. I know people who develop Web Apps will have a different list to complain about :).

I remember seeing a tweet by the Safari team that they have more openings than ever; great news, they have a lot of catch up to do! I really hope they can gain an equal footing and start having a better (bigger?) impact on the web.

And apple still has crippled version of the browser available to native app developers... that lacks support for navigator.getUserMedia and ServiceWorker...

Paul is good people. He leads Chrome's DevRel team. I was on that team from June 2015 to June 2021. Browser DevRel can be messy stuff. You're perpetually trying to advocate for your browser's vision of the web while also maintaining respectful, collaborative relations with the other browsers. The tricky part is that they often have a different vision for the web. This holds true no matter which browser you're rooting for. IMO that is the fundamental cause of all these conflicts that occasionally bubble up between Chrome/Safari/Firefox. The bright side is that the web appears to still be a functioning, open ecosystem (in that different parties are competing to take the web in different directions). Case in point you don't often see posts like this about the Android/iOS ecosystem making it to the front page of HN. Conflict is healthy albeit exhausting.

Thanks mate :) miss you.

So Apple previously requested that Safari Tech Preview be used for bake-offs instead of release Safari, then macOS 11 recently broke CI which prevented STP from being updated, and this resulted in a slide mistakenly attributing Safari with a 21 point improvement instead of 28.

Yeah... when you say it like that, it sounds like the apology really ought to be going in both directions...

Lmao what did apple do to this guy to make him write an apology about a 7-point correction from the hospital without a thumb??

They made it look like an accident

Do you have any proof that what happened was not an accident?

Everything written in the article makes sense. Is there anything out there that disproves anything that what was said?

I'm pretty sure you're replying to a joke.

The author's boss had to present the inaccurate data, and then take responsibility for it.

Even if Apple wasn't involved, that would make me want to confess.

I wouldn't even say it was that. No one asked me to write it, but I also want to make sure it was clear when and how the mistake was made. I'm not above pride in this case and in the long run I saw the two teams arguing over something that I had done and I value developers more than that.

That has to feel bad and I think you set a beautiful example for people who find themselves in this position in the future.

BTW - I still have a thumb but there is a huge huge chunk missing. :D thankfully, the hospital said a lot of the skin on the hand will heal and grow back.

Yeah I read it that way too, I meant it's in a brace or some sort of device where you can't use it so it's not there for this article.

I read it as an implication of Apple's goombas saying something like "it'll be a real shame is something were to happen to your thumb if that article gets released", but did it anyways. Too many Scorsese movies I guess.

Well, I give your attempt at keeping everyone happy 1.85 thumbs up (out of 1.85).

Best wishes on the recovery!

Dang sorry to hear about it, I sliced off a piece of my left pointer finger a couple years ago and it sucked (it’s healed and the only issue I had was my finger print changed so I had to re-register it with my phone). Missing a part of your thumb is probably worse in these smartphone times.

Sorry about that, and nice that you're almost side-effect free now.

Are you american/in america? Did you have to re-register your fingerprints?

There are opt-in programs that mandate it (security clearances, etc.), but Americans aren't generally required to register their fingerprints.

Re-register for what? I’m American only thing I had to do was fix my iPhone sign in, I still had the iPhone 6s at the time.

Oof - last week mine looked like an exploded sausage, but it was healing. Glad the long term issues weren't too bad for you.

If the Safari team could get their shit together and ship all the features they're missing that other browsers have supported for years, then perhaps I'd have more sympathy.

All I see here is that Safari still sucks in terms of feature support and developer experience.

What you're actually seeing is people who want Chrome to control the web and expect all other browsers to blindly follow whatever features they add to suit their business model.

So much this. Most of the new "features" Google keeps introducing and expressing irritation aren't supported in Safari offer significant privacy risk and dubious real world benefit.

And herein again, Google does an "Oops" like they so often did to Firefox. https://www.zdnet.com/article/former-mozilla-exec-google-has...

Chrome team no longer gets the benefit of the doubt. They are a monopoly with a history of aggressive harms to competing browsers.

Which features are you thinking about that would present a privacy risk?

I am aware of the File System Access API. What else is there?

Much of the Chrome-introduced API surfaces which aren't supported in Safari tend to be about direct access to hardware. WebUSB, WebSerial, Bluetooth API, WebXR API, etc. etc. etc.

I would generally consider the introduction of these APIs to be hostile to average users: Each one adds a new fingerprinting vector, an extremely easy malware vector, and the protections Chrome team and standards folks have designated are woefully inadequate: Average users accept basically anything, and nobody on the Chrome development team has learned that yet.

They don't introduce a fingerprinting risk if there's no permanent acceptance, only session based acceptance locked to the origin domain. And you're bashing WebXR? Without WebXR, we couldn't even have VR/AR displays work on the Web. The lack of WebXR would be hostile to any user who owns a VR headset these days.

So what, you want VR/AR to be centralized to app stores only, or to a Facebook metaverse? Because that's what's going to happen if there's no way to author and host your own VR software.

And most of the fingerprinting risk being used in the field hasn't even come from these newer APIs, but from much older APIs which surfaced versioning information or HW specific limits, or rasterization differences, without requiring any permission dialog. For example, canvas fingerprinting. Even plain old CSS could be used to detect previously visited links by styling a button and measuring it (before the bug was fixed) None of those were behind any kind of permisson dialog or container.

Can you provide an example of some ad network using WebUSB or WebSerial or Bluetooth in the wild?

> And you're bashing WebXR? Without WebXR, we couldn't even have VR/AR displays work on the Web. The lack of WebXR would be hostile to any user who owns a VR headset these days.

So, this is actually a huge part of my point, thanks for bringing it up. Nobody has a VR headset. I actually do have a very expensive VR headset, and it's sat in the box for a few years since I initially played with it. There was a craze three years back where everyone got one of those stupid Cardboards or a knockoff of it for Christmas, everyone hated it, and Google doesn't even support them anymore. I think Dell sent me one to promote one of their product lines once.

The problem here is Googlers have a completely unrealistic worldview, where stuff like having VR/AR displays work is something anyone actually cares about today. Go to a senior living complex, sit down with someone who is not in the tech industry, and see if you can help them figure out how to clean all the notifications permissions and sleezy browser extensions out of their Chrome install. Tonight I'm stopping by my parents' because my mother thinks a pinned site on her new tab page is something installed on her PC, and she wants it gone.

There are real world things Google could do to make their web browser help real human beings, but piling in new hardware APIs and then complaining other browser vendors aren't doing the same isn't what that looks like.

You should not be compromising your browser's core surface for something that at best applies to 1% of the population. Maybe these APIs have a use... as a separately installable plugin to add the functionality to the browser for the extremely niche crowd that needs them. This is true of connecting your serial device or your MIDI music interface to your browser too: It's just not something that belongs in a standard web browser toolset, and it's yet another thing I have to shut off to keep people safe on the web.

> Nobody has a VR headset.

Atleast 2 million Oculus Quests have been sold. And if no one has these devices, then WebXR is mostly useless for fingerprinting anyway.

> I actually do have a very expensive VR headset, and it's sat in the box for a few years since I initially played with it.

Goody for you. I have a Switch, Playstation, and Xbox that mostly sit rusting on the shelf as I mostly play PC games with mouse/keyboard. So therefore, my anecdote transfers to everyone?

> The problem here is Googlers have a completely unrealistic worldview

No, the problem here is, you have a derangement syndrome around Google. You rarely mention Facebook for example. Every company is working on AR/VR. Facebook, Microsoft, and Mozilla contributed major parts of the spec, but I'd say Facebook cares way more about VR these days than Google and they are betting the future of their company on it.

> It's just not something that belongs in a standard web browser toolset, and it's yet another thing I have to shut off to keep people safe on the web.

Maybe you have a point with MIDI, but musicians would probably disagree, but USB devices are ubiquitous, and VR/AR will be in the tens of millions of users within a few years, 6.1 million units predicted to be shipped this year, that's an exponential gain. And we all know that once Apple ships AR glasses, it'll explode further.

The real irony of your post is, if Facebook succeeds, Oculus will own a majority of the market, and they will control VR browsing in a Chrome fork (Oculus Browser), so they will put whatever APIs they wish into it, and Google nor Mozilla's opinion won't matter.

And if VR/AR becomes way more popular, which it seems poised to do, the fact that Chrome is 'safe' won't matter very much, and Google and Firefox will both end up implementing whatever Facebook wants to make it into their app store.

> Go to a senior living complex, sit down with someone who is not in the tech industry, and see if you can help them figure out how to clean all the notifications permissions and sleezy browser extensions out of their Chrome install.

How about you check their iPhones for how many recurring subscriptions they've been tricked into buying "1 month free", and forgot to cancel. I regularly find these on ordinary people's phones. They install apps, start a 1-month trial, and end up paying $5-10/mo zombie subscriptions for a long time before they notice.

But hey, notification permissions are the real problem, not their bank account being drained.

> No, the problem here is, you have a derangement syndrome around Google.

https://news.ycombinator.com/newsguidelines.html

> You rarely mention Facebook for example.

Facebook is incredibly easy to not use and block. Google is a monopoly in almost every space it operates in, and I've been trying to escape the great beast for five years, and I still encounter a new problem daily that can be summed up with "someone at Google thought this was a good idea, and now we have to deal with it".

Facebook is trying crazy things because it is having an existential crisis with the reality that the most profitable target demographic does not care about Facebook anymore, and probably won't any time soon.

> Maybe you have a point with MIDI, but musicians would probably disagree

I think musicians can install some sort of feature pack that adds these sorts of APIs, as everyone else doesn't need them, and a massive bloated attack surface is a bad thing to do to web browsers just for the sake of a single group. (I similarly think if you buy a VR headset, you could probably install some addition to your browser along with the inevitable hardware driver nonsense and setup.)

> if Facebook succeeds > if VR/AR becomes way more popular, which it seems poised to do

I do not think Facebook will convince everyone to strap monitors to their heads. It isn't the sort of concern that outweighs the massive problems I see day to day in real world scenarios.

> check their iPhones for how many recurring subscriptions they've been tricked into buying

This is arguably a very good concern, but Apple is probably the least worst offender here, as they wrap all those subscriptions into a single UI where you can easily remove them without having to call someone on the phone. Checking someone's credit card statement for these is far, far worse, and incredibly hard to get rid of. (Six months, two Better Business Bureau complaints, and a credit card dispute later, I finally cancelled a subscription recently.)

Then leave them disabled by default and prompt users to hand over control if a website wants it?

That would lead to web apps being as useful as some App Store apps, and that is harmful to App^w the users.

We have decades of experience about how this works in the real world. Which is that most people will blindly click whatever button is there in order to get the site to work.

For features which compromise privacy or security it’s not an acceptable approach.

That's a non-issue. If fingerprinting is your concern, people aren't going to blindly tap through 3-5 "allow ____ access to your device" dialogues before they get the hint. If it is dangerous, then Apple could issue a warning in the notification explicitly telling people that it could compromise their browsing.

WebRTC and WebMs don't compromise security anyways. Apple just reaches into their bag of canned excuses and happened to pull out "security" this time.

I think you missed the point: Nobody reads the warnings or notifications. Which is why it's absolutely an issue.

And yes, I routinely revoke permissions for dozens of sites from all sorts of Chrome permissions that the user doesn't even remember visiting, much less authorizing. People just click stuff.

Explain the fingerprinting vector of Web-Bluetooth and how it compares with CoreBluetooth? No one else has been able too

> Which features are you thinking about that would present a privacy risk?

From this week?

>Since most of us keep our phones in our pocket or on our person, there is a lot of motion data generated on the device throughout the day. Google Chrome, by design, allows any website you click on to request that motion data, and hands it over with gusto. Researchers have found that these sites use accelerometer data to monitor ad interactions, check ad impressions, and to track your device.

https://lifehacker.com/you-need-to-stop-chrome-from-sharing-...

I ran into issues needing OffscreenCanvas [1] recently. What privacy issues would that present? We were creating real world benefit with it and had to do some major over-architecting to get around it not working.

I would like to say, Firefox doesn't support it either.

[1] https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...

Except Brave/Firefox/Opera all seem to support it, and it's just Safari that's fucking us.

Brave and Opera are just Chrome in a different skin, so of course they’re going to align with Chrome.

There have been a number of issues where Mozilla has been more aligned with Apple than with Google, usually wherever there’s privacy concerns.

Or where they just don't have the resources. None of this explains why Safari's WebRTC implementation was busted, or why a lot of their CSS was lagging.

I don't think this is true. Safari has terrible audio and video support, including for WebRTC. The reason is clear: they want people to use apps instead of webpages.

And that would be a conspiracy theory. I wouldn’t make such assumptions about why Safari goes in one way or another. Priorities, patents, security, privacy, marketing… there’s all kinds of motivations that drive a team.

It’s not really a conspiracy because it’s a single company acting in its best interests. They came up a lot in Epic’s lawsuit against Apple.

https://www.theverge.com/2021/5/6/22421912/iphone-web-app-pw...

I think you mean 'ulterior motive' except its probably not even very ulterior here and it's really just a 'motive'

it's a bit of both. safari often also fails to implement sensible features in a reasonable timeframe (my personal grudge example is webp), but I do agree that chrome/google is also doing its best to choke out all other engines via API attrition

To be clear, Safari does now support webp.

Yes, my point was that it took them a really long time to add support. Sorry if that was not clear. Let's hope they don't take as long for avif

It took them until the middle of 2020 to support WebP.

Weird, I just want feature parity with Firefox.

There is a reason why Safari is the most efficient browser on the planet

Asking for more bloat is not a good idea

I wish we saw more posts like these. Refreshingly sincere, and focusing on the data itself. Kudos to the author for putting this together.

In regards to, "We realised the mistake on the morning of the keynote (November 3rd) and at that point it was too late to change it." Confused. While can understand not being able to change a number in a presentation last minute, the person reading/presenting could certainly just mention on that slide, or that number is actually x. Mistakes happen, but since they realized it before presenting why wouldn't they mention that rather than providing the knowingly wrong info?

It sounds like it was pre-recorded.

Was the whole thing not pre-recorded?

> We recorded the keynote in early/mid-October

I'm not sure when the presentation was actually made, but if it's a pre-recorded video then it makes sense they couldn't change it on the morning for either the slides or presentation. In that situation, I'm honestly not sure how I would have handled it.

Maybe they knew the number was wrong, but didn't have the correct numbers...?

It was all pre-recorded. We clarified it in the live AMA after the pre-record.

I'm having a hard time understanding why people are so worked up about such a small difference in the numbers. I read the whole post and thought both sides to be overreacting.

Am I the only one that thinks that this whole thing seems kind of...petty? A mistake was made, it was corrected ...move on?

am I missing something?

For some of us this is just the most recent event in a long series.

Is it necessarily an evil ploy this time? I say no. Should I cut them some slack? Again, I say no. When they are big enough to hurt others badly by being careless, then they should be taken to task just for being careless.

As someone said Google had mountains of goodwill until recently. When they have worked so long and so hard to make us dislike them I think they deserve to reap the rewards ;-)

Also, as someone else mentioned, there is the pattern of announcing something misleading on stage and then retracting it on a private blog later, just like big media tend to do.

>When they are big enough to hurt others badly by being careless, then they should be taken to task just for being careless

I guess this is where I'm having difficulty -- Who's being hurt badly here? What was the actual damage?

I guess I'm just having a hard time caring that google and apple are duking it out?

Like...out of all the things google does to get up in arms over, I'm having a hard time ranking getting a number wrong on a slide....and with all the things apple does, and all the resources they have at their disposal, I'm having a hard time finding much empathy for it.

I think there's a number of people who've said that they've lost trust in Google and that's pretty much the sum of it and why I felt like I needed to write up the post.

For me, there are three sets of people that I work with: Developers, Engineers in Chrome and Engineers on other browsers. Projects like Compat 2021 are super important to me to the point that if another browser vendor doesn't trust that we are working and pushing together then the project just won't succeed. If the partner browser (Safari in this question) doesn't trust the data we present, then the ecosystem won't trust the data or project. If the ecosystem doesn't trust data then the browser teams won't trust the project etc.

So even if it was just a small change in the number, it's trust all the way down.

This is a great example of why building and keeping trust is important.

If you have trust, then a honest mistake will be accepted as a honest mistake and quickly forgotten.

If trust is already strained, then even a honest mistake will be seen as an attack, blown out of proportion, and require significant work to restore the additional damage it did to the already low level of remaining trust.

Exactly. For the longest time I trusted Google.

Today I still think there are lots and lots of nice people there but I don't trust the organization anymore and I feel like a jackass for trusting them for so long.

Please note that I trust them a lot more than China or Russia, I just don't give Google the benefit of doubt anymore, they have to earn my trust and then some every single time until search works, they have provably stood up against China a couple of times, restored the browser ecosystem etc. A tall order yes, but Google is the one who could do it if they weren't so ridiculously busy with things I don't care about ;-)

I tend to agree that you should only use "release" versions of browsers when comparing features. I think it no longer makes sense to compare betas or prerelease versions.

Weird that the Safari team gets worked up over this when https://apple.com/safari regularly shows numbers based on years-old versions of Chrome.

They just updated it so it's now only Safari prerelease versus Chrome 94, but it used to compare against a one-year old version. Right after the update, it's still comparing prerelease to an outdated stable Chrome version.

Apple is very willing to intentionally make skewed comparisons to make themselves look good, but Apple apparently also gets very upset over an apparently honest mistake where a presentation that even tried to make them look good didn't make them look good enough.

I mean, it would've been the newest version at publication a year ago. Nobody expects Google to update these slides over the next year either.

Being a dynamic website vs a static slide from a presentation happened at a specific point in time, I think you are comparing apples (err..) to oranges.

They do have a clickable footnote on one of their claims which currently reads:

> Testing conducted by Apple in September 2021 by measuring page load performance of snapshot versions of 10 popular websites under simulated network conditions. Tested on production 13-inch MacBook Pro systems with Apple M1, 8GB RAM, 256GB SSD, and prerelease macOS Monterey. Tested with prerelease Safari 15.0 and Chrome v94.0.4606.61. Performance will vary based on usage, system configuration, network connection, and other factors.

And in August 2021, it read:

> Testing conducted by Apple in October 2020 by measuring page load performance of snapshot versions of 10 popular websites under simulated network conditions. Tested on production 1.4GHz quad-core Intel Core i5-based 13-inch MacBook Pro systems with 8GB RAM, 256GB SSD, and prerelease macOS Big Sur. Tested with prerelease Safari 14.0.1 and Chrome v85.0.4183.121. Performance will vary based on usage, system configuration, network connection, and other factors.

In September 2020, they posted a clickable footnote with:

> Testing conducted by Apple in August 2019 using Jetstream 2, MotionMark 1.1, and Speedometer 2.0 performance benchmarks. Tested on production 1.4GHz quad-core Intel Core i5-based 13-inch MacBook Pro systems with 8GB RAM, 256GB SSD, and prerelease macOS Catalina, and Windows 10 Home, version 1903, running in Boot Camp. Scores represent browsers that completed the test. Tested with prerelease Safari 13, Chrome v76.0.3809.100, and Firefox v68.0.2 on macOS, as well as Chrome v76.0.3809.100, Microsoft Edge v44.18362.267.0, and Firefox v68.0.2 on Windows Home, with WPA2 Wi-Fi network connection. Performance will vary based on system configuration, network connection, and other factors.

Could they constantly update this piece of information? Sure. But I think they're being pretty up front and clear about what they're saying. And it seems like they do similar testing every year, at a fairly regular interval. I see no evidence that they're doing anything wrong here.

I think it's a pretty high bar to expect that all web pages must always show the latest possible data.

Edit: I actually pulled slightly different footnotes accidentally, since the pages have updated over time. But in general, all testing clearly points to the months where the testing occurred. I think the worst thing I saw was in 2018, I think they had some tests which used data in August and October. Which I don't love. But I didn't notice that happening recently, and they did clearly disclose it.

> September 2021 ... prerelease Safari 15.0 and Chrome v94

It looks like in September 2021 Chrome v94 was in either Beta or Stable depending on when in the month they were testing. [1] Assuming they picked their versions early in the month, this seems very reasonable.

> October 2020 ... prerelease Safari 14.0.1 and Chrome v85

In October 2020 Chrome Beta was v86 and then v87 (2020-10-15), so this is less reasonable: prerelease Safari vs stable Chrome.

> August 2019 ... prerelease Safari 13, Chrome v76

In August 2019 Chrome beta was v76 and then v77 (2019-08-08). Assuming they picked their versions at the beginning of the month, this is fine.

[1] https://chromiumdash.appspot.com/schedule

(Disclosure: I work for Google, speaking only for myself)

They say "prerelease" Safari because it's the version they're marketing, but they test it before they officially release it so the marketing materials are ready. That version of Safari would've been current at publication time.

That's a good point: if they are literally about to release it, it's much more similar to stable than beta.

I tried to look at historical timing, and it's kind of confusing. For example, Apple said they tested "prerelease Safari 14.0.1" in October 2020. But the initial Safari 14 came out on 2020-09-16, an 14.0.1 was a security update released on 2020-11-12 (which I would expect not to have any web compatibility or performance changes).

My overall takeaway is that what Apple is doing here is unremarkable and not misleading.

> But I think they're being pretty up front and clear about what they're saying. And it seems like they do similar testing every year, at a fairly regular interval. I see no evidence that they're doing anything wrong here.

Is this a failed attempt at sarcasm?

Apple takes the small print to an art, in addition to being several pages of scrolling away from the actual claim. Even presented with normal typography here on HN, the text is so unreadable that my eyes try to glance off of it, and I'm a technical users that knows what the text means!

If you want to publish this kind of "snapshot" information, either publish somewhere where that is clear from context (like a blog), or at the very least make sure that the inline content makes it very clear! For example: "In October 2020, we found that Safari caused the battery to last 10% longer the then-latest version of Chrome".

Publishing this kind of claim as evergreen and then pointing at the small print when anyone complains (as if anyone in the actual target group actually read that) is effectively fraud.

So I read your comment expecting to be mad at Apple, but a quick look at the Wayback Machine [1] disproved almost everything you wrote.

> They just updated it

Last month would be a more accurate description [2].

> but it used to compare against a one-year old version

What actually happened is that they hadn't updated the data on their website for a year. That's very different from "comparing it against a one-year old version." They were at no point comparing the latest version of Safari against a year old version of Chrome.

> Apple is very willing to intentionally make skewed comparisons

It looks more like you're willing to make intentionally skewed projection of facts.

[1]: https://web.archive.org/web/*/https://www.apple.com/safari

[2]: https://web.archive.org/web/20211026001113/https://www.apple...

Maybe both of you are right?

I'm sure Apple's page was factual and up-to-date at the time it was posted, but Chrome's faster dev cycle means that the Chrome data is outdated long before the next year when Apple updates Safari.

That's very different from "comparing it against a one-year old version.

The outcome of Apple not keeping their page up to date is that they were misleading the user by comparing Safari to a version of Chrome that is no longer current, or relevant. The action (or inaction strictly speaking) might be different, but the result is the same.

Apple have enough staff that they could keep a page up to date if they wanted to. They chose not to.

> misleading the user by comparing Safari to a version of Chrome that is no longer current, or relevant

If they had continued to update the version of Safari in their comparisons without updating the version of Chrome I agree that would be misleading. But leaving the comparison frozen because they haven't updated their page is just the normal difficulty of keeping things up-to-date.

(Disclosure: I work at Google, speaking only for myself)

The updated numbers generally seem to favor Safari. The outdated numbers were only misleading in the sense that it benefited Chrome, not Safari.

That's not how that works when Safari gets much more infrequent updates.

What you're implying is highly unlikely since browser performance doesn't change so dramatically every few weeks as to make your claim possible.

https://arewefastyet.com/win10/benchmarks/overview?numDays=3...

It changes over the course of 6 months. So after 6 months the comparison is very outdated, and the comparison wouldn't benefit Chrome.

Multiple updates for Safari are delivered over the course of six months. And note that the graph I've shown you plots the daily performance of browsers for the past year.

I agree with you that there was nothing wrong with Apple posting a page after a Safari release, comparing it with the Chrome version at the time, and then not updating the page until their next significant Safari release.

However, it is true that Safari gets feature updates much less frequently than Chrome or Firefox. Historically, there's the integer update in the fall (13 to 14 to 15) followed by the .1 update in the spring. Those are when features are added. The Safari updates that happen in-between are only bugfixes; some bugfixes may have performance implications but they don't include improvements to language support (HTML, CSS, JavaScript).

Safari 15.1 is already out but I think they only used that version number because it includes a significant UI change (to tabs), it's not an indication that they're moving to a faster release cadence for features.

> They were at no point comparing the latest version of Safari against a year old version of Chrome.

They tend to update that page after a Safari update, which is yearly. They tend to highlight benchmarks that Safari looks good in. If Chrome and Firefox then optimize these highlighted benchmarks and catch up on these benchmarks within a month, Apple still has that page show the old data for a year. And for next year's release they again pick the benchmarks that look best for them at that moment in time and keep the numbers up for a year. Even though this update cadence guarantees that the numbers are outdated and misleading for the majority of the time they're up.

> They tend to update that page after a Safari update, which is yearly

So you very well knew Apple weren't "comparing against a one-year old version."

> And for next year's release they again pick the benchmarks that look best for them at that moment in time

They're using the exact same benchmarks as last year, and the numbers seem to be improving for Safari. May I remind you I actually checked the past version of Apple's website on the Wayback Machine?

I'm not the GP author, but I don't think they actually said that _exactly_. I agree it was a bit vague, but the latter point of them using an old version of Chrome for their most recent update was more pertinent. They are comparing a pre-release to a stable in both cases and then not spending any effort to contrast that later.

I like their honesty though it's in the small print "Not all features are available on all devices."

I don't think I want to work anywhere that has this level of angst.

This should go in a textbook about great professional apologies.

I'd like to make a note that these tests do not cover feature differences within the Safari ecosystem since this is only comparing Safari macOS (the only OS that allows other browser engines). Safari on iPadOS has fewer features available than Safari on macOS, iOS even less. Missing features between Safari for each OS are either because they default to off (but the user can enable them) or they are explicitly not available. For instance iPadOS supports MSE (Media Source Extensions) but iOS does not, despite them running on the same SoC. I do not recall having encountered such differences with other engines between different desktop/mobile operating systems.

Since Safari on iOS has the greatest number of users of all the Safari versions it should be used for comparison, and not Safari macOS.

I just want to commend Paul on a classy apology.

A lot of people are saying "it's not a big deal", and frankly, it might not be, but some safari developers felt that the work they put in wasn't respected, and Paul came out and gave a mea culpa.

Whether it's a big deal or not, if people's feelings are hurt, I think it's best to address it and apologise rather than to say "it wasn't that bad" especially when you've made a mistake.

Mistakes happen Paul. Well done for coming out and owning it.

Sliced off his thumb and still made time to write this!

:thumbs-up: - I've got some gnarly pictures, but I can say I am on the mend.

What issues are people actually facing in regards to browser compatibility on evergreen browsers in 2021? I keep hearing people complaining about Safari but no one has explained what issues they actually face.

The article mentions CSS but I've not encountered any incompatibilities so far. I've made SPAs, normal sites, used CSS Grid, some simple animations, all been fine across browsers.

My most recent issue was with the ElementInternals API: https://developer.mozilla.org/en-US/docs/Web/API/ElementInte...

They still don’t have it implemented despite giving their “strong support” a few years ago when the API was in the final spec stage. That’s really the crux of the issue - they always seem a few years behind in implementing any new spec.

Firefox hasn't exactly implemented it either.

No, but at the very least Firefox has the bare minimum needed not to crash js execution when it encounters usage of the API. Safari doesn't recognize the syntax (or at least didn't when I tested this ~5 months ago, though it looks like nothing has changed on the safari side).

Wow thats terrible actually. I remember looking into how to get web components to work with forms and decided to put it off for a while. Didn't know Safari doesn't implement it yet. Is there a polyfill?

There is: https://github.com/calebdwilliams/element-internals-polyfill

webp also took them ages and hopefully avif won't take as long as webp did

Safari was slow to support the `gap` property for Flexbox and still doesn't support it for multi-column layout (e.g. `column-count: 2;`). They were slow to support the `aspect-ratio` property. Safari doesn't support `:focus-visible` (this is a weird one because Safari's `:focus` is already comparable to `:focus-visible` but not supporting the new pseudo-class really complicates how CSS rules have to be written).

On the other hand, Safari supported `:is()`, `:where()`, and ::marker before Chrome. There have been other cases of Safari being earlier and not just for things they've originated.

>Safari was slow to support the `gap` property for Flexbox and still doesn't support it for multi-column layout (e.g. `column-count: 2;`).

https://caniuse.com/?search=column-count

Yes, Safari supports `column-count`. I wrote it still doesn't support using `gap` with it.

https://caniuse.com/mdn-css_properties_gap_multicol_context

Someone made a mistake. Correct it. Move on. Why so apologetic? I personally never apologize for an honest mistake. Humans make mistakes, I make mistakes, mistakes happen, and if it's not a big deal, then there's no need to apologize imo. Apologizing too often leads to a culture where failures are not embraced.

Couldn't disagree more. To me, an apology signals that a mistake was made, noticed, embraced, (hopefully) corrected, and learned from. There's no shame or opprobrium attached to an honest apology, and plenty of potential for improvement. There's quite the opposite attached to a person who blithely handwaves away their own mistakes without any acknowledgement.

Very honorable of Paul going out there, assuming the mistake and making this write up.

> Longer term, I'm going to be directing my teams to focus more on broad browser support in our work and less on newer Chrome-first (/only?) features

Not focusing on Chrome-only features? Interesting.

Sorry to hear that with your thumb. I guess safari devs made it clear that if you shit on their browser you will next time lose more than a thumb. These animals…

I've given up on Safari - it's buggy as hell, seems to ignore the most interesting standards available on every other browser and is just generally not a great experience for me as a developer or as a user.

I am happy that they gave the world WebKit[°], but they absolutely destroyed that good will by providing the worst-of-breed dev tools (assuming they're even working in a particular release) and failing to support web standards properly that could have driven the web forward (ie: WebRTC).

[°] EDIT: I am aware that it was forked from KHTML but it was still a big engineering effort

> the most interesting standards available

Genuine question — which standards is it you have in mind?

Restricting the list just to the ones I can find on caniuse or bugzilla, but this is a tiny, tiny subset. It also doesn't include the fact that implementations are completely busted (IndexedDB for the longest time [1], ServiceWorkers [2])

https://caniuse.com/av1

https://caniuse.com/mdn-css_properties_contain

https://caniuse.com/css-overflow-anchor

https://caniuse.com/css-focus-visible

https://caniuse.com/js-regexp-lookbehind

[1] https://bugs.webkit.org/show_bug.cgi?id=226547

[2] https://bugs.webkit.org/show_bug.cgi?id=187461

Adding on to this, WebRTC really doesn't work well, especially on mobile. Also, you can't set the volume on video and audio elements on mobile, which really limits what you can do. The audio context implementation is also pretty buggy.

Fullscreen API on iPhone. Chrome on Android supports the fullscreen API, I use it to create interactive demos, however iOS (iPhone) Safari does not. Inexplicably, it's supported on iPad, but not iPhone. Why???

https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_...

MSE media source extensions - supported on macOS and iPadOS but not iOS for an unknown reason (was available off by default in one iOS beta though).

You may not be interested in Safari, but Safari is interested in you.

True, albeit WebKit started as a fork of KHTML, KJS and KSVG from KDE - and KHTML was already pretty damn amazing (at the times I was using it instead of Firefox).

They didn't give us Webkit. They forked an already really good project in KHTML.

I wish I could give up on Safari but I have an iPhone.

And there I am tasting only with Firefox and Safari.

This reeks of "oops we're sorry" described by Johnathan Nightingale (former General Manager and Vice President of the Firefox group) in his thread on how Google was sabotaging Mozilla: https://archive.vn/tgIH9 (or direct link, https://twitter.com/johnath/status/1116871237240852480)

- "I'm sorry for the misrepresentation of Safari Tech Preview's compatibility score".

This was intentional. Show these numbers at a large dev summit. Post an apology on a personal blog a week later.

Related: https://news.ycombinator.com/item?id=29228083 (the mistake was noted before the summit, but wasn't even mentioned)

- "it stated that Safari had jumped from a score of 64 => 85, when in fact what we should have had on the slide is is 64 => 92."

Yup. It still shows 86

- "I hadn't seen any negative press or negative developer sentiment to this slide, but it clearly irked the Safari team."

Any negative news presented by Chrome team is uncritically taken at face value and accepted as truth. This is very well known to the Chrome team and they are very happy to exploit this.

- "Compatibility is a shared ecosystem problem. It makes no sense to me that we try and score 1-up points on Compatibility. Just because one browser might be on spec, it also means that same browser might also not be interoperable with other browsers and this means that developers have to deal with the difference irrespective if a browser is "technically correct""

Chrome should stop pretending they are good guys. They are not. They keep implementing increasingly Chrome-only APIs and ignoring any and all concerns about those APIs from Firefox and Safari. They couldn't care less if Chrome wasn't interoperable with other browsers because in their minds Chrome has already won.

- "Longer term, I'm going to be directing my teams to focus more on broad browser support in our work and less on newer Chrome-first (/only?) features and I think our wider story should all be based on what users have today, and less on what they might support at some point in the future."

This will never happen. "You have to run twice as fast just to keep up with Chrome" is an insanely successful strategy for Chrome. If anything, Chrome-only work will only accelerate.

In a couple of years I expect FE requirements to list "ChromeOS development in X years" instead of plain Web skills.

This seems overly cynical. Did you read the post? The anxiety there seems genuine to me.

If it really was intentional, then either the author is a sociopath, or I'm an easy mark. But I'd prefer to believe neither of those are the case.

> This seems overly cynical. Did you read the post?

I did. I've also read and seen a lot of what Google and Chrome have been doing for the past few years.

And, to quote John Nightingale (do read his thread):

--- start quote ---

The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional

--- end quote ---

Totally agree with that sentiment for group decisions (e.g. decisions on which APIs to support) but this is a blog post from an individual talking about their mistakes as an individual. They get my benefit of the doubt.

I think the number of API's we add to the platform will always keep increasing. We certainly see a big part of the web as enabling Apps to come to the web, and we do make sure (now) to have developers committing to using those APIs. I know that also frustrates a lot of people too.

It's sad that it's got the point where the teams don't trust each other and it's clear that the perception is wider. I'm still hoping to change that around.

I wrote the post to as clearly as possible document what happened for the avoidance of doubt because it was me who made the mistake. I'll accept your point of view, but I'm also comfortable with my side of this.

I've nothing against Chrome developers, but if you think honestly about the web and Google, would it not be true that:

- after Chrome was introduced, the web has gone from a healthy and steadily improving ecosystem to a monoculture?

- cross browser compatibility has gone from steadily increasing as IE was replaced by other browsers to declining as people are testing only in Chrome

- if Chrome "wins" it will it not be a matter of months before Google "unfortunately" have to cripple the extensions API?

- do you really think that the development of new features in Chrome will continue at its current speed if Chrome "wins" or do you think it will be put on hold like IE6? (Remember, Google unlike Microsoft is famous for killing projects people love.)

You don't have to answer me, but think about it.

You are probably good people with good intentions, but isn't it a fair chance that you are getting used by management to do something you'd rather not have on your resume: killing the free and open web?

> - cross browser compatibility has gone from steadily increasing as IE was replaced by other browsers to declining as people are testing only in Chrome

The irony of highlighting this is that the subject for this story is a cross-browser test suite and the issue was that Chrome, Firefox, and Safari were more compatible than the published numbers suggested.

There will always be cross browser bugs and so developers will always need to test everywhere, but the more mainstream features have compatibility rates like this in the first place the less often "works only in browser x" happens by accident.

Good catch. That said I'm just trying to reach out to the Web and Chrome Developer relations lead, and this seemed like as good a chance as I'd get.

Heh - It's hard to answer these questions when they are posited as loaded questions so clearly :D

I don't think it's about Google or Chrome winning. I believe Google is pretty clear that a healthy and open web where anyone is able to freely publish, monetize and consume content, as well as build and use apps is important for it's business and success. I think Google has a part to play in the success of the web, I think I can help be a force for good in the success of the web, however we're just parts of the ecosystem whole and the web will be around still long after Google.

I don't believe new features in Chrome will ever stop because we still believe the web should be able to do everything that other platforms can do and we want to keep offering that to people.

> I believe Google is pretty clear that a healthy and open web where anyone is able to freely publish, monetize and consume content, as well as build and use apps is important for its business and success.

This is the funniest thing I've read in a long time on HN. Coming from a Chrome DevRel I can't understand if it's irony, because you can't possibly believe this.

Google is an online advertising company. 80% of Google's money comes from online advertising. An open web where everyone can do what they please is an existential threat to the company you work for. And for the past many, many years Google has done a lot of things to tighten its control over the web.

I mean, with all the recent news about AMP from just last week, how can you possibly say that "Google wants everyone to publish and monetise freely".

> I think I can help be a force for good in the success of the web, however we're just parts of the ecosystem whole

There's no "ecosystem whole", and Google is doing everything in its power to make sure that there's even less of an ecosystem.

I know we're not going to agree. I know Google is advertising as major source of revenue. I also believe that it can only successful advertise through its search because the web is open and needs to stay that way.

The existence of AMP alone (and what Google did with it) invalidates your statements entirely.

> I think the number of API's we add to the platform will always keep increasing.

The problem isn't the the number of APIs per se (though I agree that it's unsustainable [1][2]).

It's how they get forced onto the web by Chrome.

- Implementing Chrome's internal API and pushing them to stable, and pretending they are a web standard? Check (Example: Web HID, original "spec" couldn't be understood by Mozilla engineers, updated "spec" was published two months after Chrome enabled it by default and published an article on web.dev)

- Ignoring Mozilla and Safari concerns on an API, enabling in stable because Google's own projects want them, and refusing to bring it back under flag? Check (Constructible Stylesheets, in the end Safari refused to implement them, period)

- Gaslighting other browser vendors through any means possible to an audience of thousands? Check (Alex Russel and the likes of him)

And that's off the top of me head, too late here where I am going through dozens and dozens of such instances I saved to document in a blog post one day.

> It's sad that it's got the point where the teams don't trust each other and it's clear that the perception is wider. I'm still hoping to change that around.

I will quote John Nightingale [3]

--- start quote ---

--- end quote ---

All this is very intentional behaviour that has been going on for years. No wonder Safari team is pissed.

[1] https://www.quirksmode.org/blog/archives/2015/07/stop_pushin...

[2] https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

[3] https://twitter.com/johnath/status/1116871251023278080

Minor aside: Alex is currently a PM on Edge https://twitter.com/slightlylate

(I also don't know what you're referring to with the "Gaslighting" comment)

Yup. The moment he went to Microsoft his tune changed and now Google is a bad guy, too: https://infrequently.org/2021/07/hobsons-browser/

His twitter (often) and website (infrequently) is full of claiming Safari is bad, Safari is holding the web back, Safari is the evil browser etc. While of course ignoring all the issues in Chrome (until going to MS).

And he's not alone.

FWIW I work at Google (speaking only for myself) and think https://infrequently.org/2021/07/hobsons-browser/ was a good post. It points out problems with Google's approach that I am happy to see more discussion of, and in most cases I agree with him.

Appreciate you adding this extra information in (also hey! on Twitter).

I don't have much to add, I understand it and I don't disagree with the frustration you have, because it's also not the first time I've heard it from many developers.

I'll keep working with the team to improve it, but it certainly takes time.

> I can see arguments on Twitter and I really want them to stop because it's making us all look bad.

Get off Twitter.

That wouldn't make the arguments disappear. The author is a DevRel for Chrome, for better or worse they have to go where the audience is. It's literally their job.

Yeah - I have to take the rough with the smooth. :D

Quite honestly, Twitter makes anyone and everyone look bad at some point.

Reply on news.ycombinator.com