[HN Gopher] Sorry Safari Team
___________________________________________________________________
Sorry Safari Team
Author : tosh
Score : 189 points
Date : 2021-11-15 11:50 UTC (11 hours ago)
(HTM) web link (paul.kinlan.me)
(TXT) w3m dump (paul.kinlan.me)
| nobleach wrote:
| 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.
| taf2 wrote:
| And apple still has crippled version of the browser available
| to native app developers... that lacks support for
| navigator.getUserMedia and ServiceWorker...
| londons_explore wrote:
| 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...
| serverholic wrote:
| 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.
| syspec wrote:
| 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
| magicalist wrote:
| > _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
| sangnoir wrote:
| > MacOS 11 isn't allowed(?) to be virtualized
|
| IANAL, but IIIRC, MacOS isn't allowed to be virtualized _on
| non-Apple hardware_
| freediver wrote:
| All browsers got to be compared on their bleeding edge/canary
| builds for this, not just Safari.
| realusername wrote:
| 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.
| jgraham wrote:
| 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.
| GoodJokes wrote:
| What fragile people got upset about a number to the point that
| this person had to write this apology.
| [deleted]
| mmastrac wrote:
| 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[deg], 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).
|
| [deg] EDIT: I am aware that it was forked from KHTML but it was
| still a big engineering effort
| krrrh wrote:
| You may not be interested in Safari, but Safari is interested
| in you.
| jokethrowaway wrote:
| 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).
| neilalexander wrote:
| > the most interesting standards available
|
| Genuine question -- which standards is it you have in mind?
| mmastrac wrote:
| 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
| wildrhythms wrote:
| 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_...
| rp1 wrote:
| 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.
| soperj wrote:
| They didn't give us Webkit. They forked an already really good
| project in KHTML.
| artificialLimbs wrote:
| I wish I could give up on Safari but I have an iPhone.
| timeon wrote:
| And there I am tasting only with Firefox and Safari.
| heavymark wrote:
| 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?
| BuildTheRobots wrote:
| > 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.
| londons_explore wrote:
| Maybe they knew the number was wrong, but didn't have the
| correct numbers...?
| kinlan wrote:
| It was all pre-recorded. We clarified it in the live AMA after
| the pre-record.
| chaboud wrote:
| It sounds like it was pre-recorded.
| mnd999 wrote:
| Was the whole thing not pre-recorded?
| fron wrote:
| 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.
| Shadonototra wrote:
| There is a reason why Safari is the most efficient browser on
| the planet
|
| Asking for more bloat is not a good idea
| robertoandred wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| lghh wrote:
| 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...
| sefrost wrote:
| 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?
| GeekyBear wrote:
| > 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-...
| ocdtrekkie wrote:
| 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.
| cromwellian wrote:
| 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?
| ocdtrekkie wrote:
| > 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.
| smoldesu wrote:
| Then leave them disabled by default and prompt users to
| hand over control if a website wants it?
| threeseed wrote:
| 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.
| smoldesu wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| sangnoir wrote:
| That would lead to web apps being as useful as some App
| Store apps, and that is harmful to App^w the users.
| mtomweb wrote:
| Explain the fingerprinting vector of Web-Bluetooth and
| how it compares with CoreBluetooth? No one else has been
| able too
| asddubs wrote:
| 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
| jonny_eh wrote:
| To be clear, Safari does now support webp.
| asddubs wrote:
| 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
| soperj wrote:
| Except Brave/Firefox/Opera all seem to support it, and it's
| just Safari that's fucking us.
| kitsunesoba wrote:
| 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.
| cromwellian wrote:
| 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.
| rp1 wrote:
| 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.
| azinman2 wrote:
| 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.
| freejazz wrote:
| I think you mean 'ulterior motive' except its probably
| not even very ulterior here and it's really just a
| 'motive'
| rp1 wrote:
| 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...
| syspec wrote:
| Clearly didn't read the article
| chrsig wrote:
| 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?
| skinkestek wrote:
| 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.
| chrsig wrote:
| >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.
| kinlan wrote:
| 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.
| tgsovlerkhgsel wrote:
| 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.
| skinkestek wrote:
| 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 ;-)
| 0des wrote:
| I wish we saw more posts like these. Refreshingly sincere, and
| focusing on the data itself. Kudos to the author for putting this
| together.
| havkd wrote:
| > I can see arguments on Twitter and I really want them to stop
| because it's making us all look bad.
|
| Get off Twitter.
| afavour wrote:
| 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.
| kinlan wrote:
| Yeah - I have to take the rough with the smooth. :D
| ronsor wrote:
| Quite honestly, Twitter makes anyone and everyone look bad at
| some point.
| lloydatkinson wrote:
| 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.
| jjcm wrote:
| 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.
| asddubs wrote:
| webp also took them ages and hopefully avif won't take as
| long as webp did
| lloydatkinson wrote:
| 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?
| jjcm wrote:
| There is: https://github.com/calebdwilliams/element-
| internals-polyfill
| robertoandred wrote:
| Firefox hasn't exactly implemented it either.
| jjcm wrote:
| 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).
| extra88 wrote:
| 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.
| brunojppb wrote:
| Very honorable of Paul going out there, assuming the mistake and
| making this write up.
| mmcnl wrote:
| 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.
| phillipseamore wrote:
| 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.
| bla3 wrote:
| 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.
| [deleted]
| ezfe wrote:
| 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.
| darkwater wrote:
| 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.
| FemmeAndroid wrote:
| 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.
| jefftk wrote:
| _> 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)
| ezfe wrote:
| 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.
| jefftk wrote:
| 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.
| Nullabillity wrote:
| > 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.
| soraminazuki wrote:
| 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...
| onion2k wrote:
| _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.
| jefftk wrote:
| _> 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)
| soraminazuki wrote:
| The updated numbers generally seem to favor Safari. The
| outdated numbers were only misleading in the sense that it
| benefited Chrome, not Safari.
| soperj wrote:
| That's not how that works when Safari gets much more
| infrequent updates.
| soraminazuki wrote:
| 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?numDay
| s=3...
| soperj wrote:
| It changes over the course of 6 months. So after 6 months
| the comparison is very outdated, and the comparison
| wouldn't benefit Chrome.
| soraminazuki wrote:
| 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_.
| extra88 wrote:
| 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.
| bla3 wrote:
| > 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.
| soraminazuki wrote:
| > 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?
| invisible wrote:
| 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.
| madeofpalk wrote:
| 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.
| kaycebasques wrote:
| 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.
| kinlan wrote:
| Thanks mate :) miss you.
| hnarayanan wrote:
| Sliced off his thumb and still made time to write this!
| kinlan wrote:
| :thumbs-up: - I've got some gnarly pictures, but I can say I am
| on the mend.
| hit8run wrote:
| 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...
| [deleted]
| bangonkeyboard wrote:
| 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.
| londons_explore wrote:
| Yeah... when you say it like that, it sounds like the apology
| really ought to be going in both directions...
| gtirloni wrote:
| 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.
| diebeforei485 wrote:
| 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.
| evrydayhustling wrote:
| This should go in a textbook about great professional apologies.
| dmitriid wrote:
| 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.
| kinlan wrote:
| 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.
| eitland wrote:
| 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?
| magicalist wrote:
| > _- 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.
| eitland wrote:
| 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.
| kinlan wrote:
| 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.
| dmitriid wrote:
| > 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 ---
|
| 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 ---
|
| 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_pus
| hin...
|
| [2] https://drewdevault.com/2020/03/18/Reckless-limitless-
| scope....
|
| [3] https://twitter.com/johnath/status/1116871251023278080
| jefftk wrote:
| 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)
| dmitriid wrote:
| 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.
| jefftk wrote:
| 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.
| kinlan wrote:
| 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.
| wbobeirne wrote:
| 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.
| dmitriid wrote:
| > 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 ---
| wbobeirne wrote:
| 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.
| pjmlp wrote:
| In a couple of years I expect FE requirements to list "ChromeOS
| development in X years" instead of plain Web skills.
| jacknews wrote:
| I don't think I want to work anywhere that has this level of
| angst.
| antonzabirko wrote:
| 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??
| kinlan wrote:
| 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.
| vxNsr wrote:
| 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.
| kinlan wrote:
| Oof - last week mine looked like an exploded sausage, but
| it was healing. Glad the long term issues weren't too bad
| for you.
| temp_praneshp wrote:
| 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?
| jmgao wrote:
| There are opt-in programs that mandate it (security
| clearances, etc.), but Americans aren't generally
| required to register their fingerprints.
| antonzabirko wrote:
| 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.
| dylan604 wrote:
| 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.
| ethbr0 wrote:
| Well, I give your attempt at keeping everyone happy 1.85
| thumbs up (out of 1.85).
|
| Best wishes on the recovery!
| [deleted]
| pdenton wrote:
| They made it look like an accident
| mynameisvlad wrote:
| 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?
| mst wrote:
| I'm pretty sure you're replying to a joke.
| droopyEyelids wrote:
| 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.
| kinlan wrote:
| 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.
| droopyEyelids wrote:
| That has to feel bad and I think you set a beautiful
| example for people who find themselves in this position in
| the future.
___________________________________________________________________
(page generated 2021-11-15 23:02 UTC)