I'm fortunate enough to be in another job now where we don't need iOS web support so we can tell customers that we won't fix it, in my past job where I had to it was very hard to keep up with the constant stream of broken safari releases, every one of them being broken in different ways.
I sympathize with those who still do and I'm looking forward to EU regulations to allow other rendering engines.
Supporting iOS and macOS in webdev is an absolute nightmare and a big reason why I left that space and am not planning to go back until something fundamentally changes.
It's clear that they're still trying to undermine the web where possible, without it seeming too obvious or getting them into hot water re: the recent monopolization debate.
While I get where the 'undermine' narrative is coming from, there are other, IMO more plausible, reasons why support is difficult:
- Apple doesn't want others to dictate their development schedule.
- Some Web standards clash with Apple's privacy promises.
While I'd like Apple to do a bit more about those long standing bugs, I think the narrative they are actively undermining the web is short sighted. I prefer Apple's behaviour instead of Google's behaviour to actively monopolise the web...
Yes, thank you for speaking up to defend Apple’s prerogatives here. No one should have to suffer through the (checks notes) privacy violations and grueling six-year implementation timeline of adding a date picker input to their browser.
I wish HN had more complaints like this, and not the usual "whatever is the latest Chrome API of the day we need it in all browsers now!"
---
As a tangent. If it was Apple of, say, 5-10 years ago, I'd also root for them to get their head out of their ass and lead in https://open-ui.org/ (started, of all people, by devs from Microsoft). Alas, with the way they approach interfaces these days, I'd want them far away from leading :)
I 100% agree with the sentiment and I have suffered a lot because of that. But I will say things seem to be slowly progressing.
Webkit is releasing more often and closer to the standards now than they used to. I'm guessing Apple knows they will be forced to allow other engines on iOS and are finally making Safari a good product.
Safari is to browsers today what IE once was: dread by those that have to support them.
I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance.
I hope the C-level exec at Apple sees this and realises why more devs are going to go with Edge (lol) / Firefox support: the sales guys are running Apple now.
Nothing beats Safari in terms of battery usage, and there are features like the reading list that work really well (for me). For development, yes, I always have Chrome installed in case I needed it.
For me, a Firefox user, I don't share your point of view. I see a lot more "optimized for Chrome" or "run this in Chrome because that is the only browser we decided to support" because Google decided on implementing some feature of their own making. Never have I been hindered in my web browsing by something tailored to Safari.
It was not just that IE was broken in all sort of very odd ways, or that it was incompatible with the rest (and standard), or that it was essentially a monopoly.
It was all three. So a site built for IE would not work at all in other browsers if it used anything remotely advanced (and advanced back then was users events), you had to support IE to live (on anything but demo site), and doing so was hell on earth because the bugs went from top to bottom (the browser’s memory management had to be worked around, and there were no memory profiler, hell the debuggers only worked half the time).
Not that it’s any fun encountering a buggy browser, even less so when a feature is so broken you’d be better off if it were not supported and just did nothing or used a fallback and you now have to coerce it into that, and it does seem to be a recurring issue of safari.
But it’s no IE, at this point you’d need malice aforethought to get there.
Also, typed arrays being slower than normal arrays for years on Chrome (and therefor pretty useless), Chrome breaking audio buffer playback for several major iterations, etc. This "whatever Chrome does is the standard" attitude reminds somewhat of the days of IE6 devs.
It’s exactly what the article describes. Because Safari was correctly implementing something and not reproducing a Chrome bug, the dev is asking Apple to change their release structure to reduce their stress.
This is the endgame of a monopoly. Other people start demanding others stop fairly competing with you.
> I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance.
I'd like to think I'm a competent dev.
I use Safari as my daily driver because the difference in performance/battery life on Apple silicon is worth whatever small incompatibilities I run into. It just doesn't ever impact me on a day-to-day basis in the way that performance and battery life do.
Good engineering is all about trade-offs and this is one that doesn't even require a second thought for me.
I use Safari as my main browser too. The features that link it between Mac and iPhone are very nice and easy to use.
What also is cool in Safari is to zoom into a page so that everything gets bigger which makes it easier to read text or view pictures (not sure if this is the normal zoom a site has, or something on top OS wise). But a lot of sites are breaking that behaviour now, which results in either not being able to zoom or elements overlapping in weird ways, text not staying where it should. I wonder what CSS stuff is used there.
Why would they care what devs do? They are an infinitesimal minority.
Their product are status/convenience for "normal" people, and they will use whatever browser Apple ships and if something breaks it's anybody else's fault.
"If your Mac can't run it you don't need it".
raises hand I think I'm a competent developer and I use Safari primarily. The number of times I've tried to build something and found out that Firefox or Chrome got halfway through the spec and then stopped working on it isn't 0 either. It goes both ways.
I switched to a Safari-first approach for web development a while back and it has reduced my pain considerably. In fact I use it as my main daily driver browser in general now.
I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.
It does because you notice you've run into a webkit bug and work around it. A surprisingly high number of sites have core functionality like signin, nav or payment broken on safari and apparently aren't aware of it.
This is an exceptionally smart outlook; and reflects my own experience - if something is wrong in my code in Safari it is usually wrong elsewhere.
There's an important and cool concept here about using the weakest link sometimes.
Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have.
If my app runs well on my iPhone 8, it's obviously going to scream on a 12.
"Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."
1. IE6, a titanic that that wants to harm the web so they can push their own ecosystem instead.
2. IE11, the incompetent and rarely updated browser that you have to support because a segment of your userbase is stuck with it.
This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role. Ensuring apple gets their app store cut.
How is that a retcon? I believe Microsoft and IEs stagnation was to keep people using Microsoft software instead of the web.
The primary reason for chrome being developed in the first place was to push the web into a place that stuff like Google maps, docs, and so on could exist at all.
> It needs as much argument, if not more.
Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
> The primary reason for chrome being developed in the first place was to push the web into a place that stuff like Google maps, docs, and so on could exist at all.
Retcon again.
> Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browsers, and want Chrome-only non-standards delivered yesterday to every browser.
To quote again, "But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."
> The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
I do web dev, and it is definitely not immediately apparent.
After IE6 achieved it's goal of destroying the competition, Microsoft literally disbanded the development team. Why would they do that for a very successful product? Because the web didn't have potential?
Firefox started innovation back again a bit, but it took chrome and Google's want to applicationize the web to really kick us into gear.
> A few days before Google Chrome launched, Google released a blog post titled “A fresh take on the browser.” The post explained that they were releasing this new browser because they believed they could “add value for users and, at the same time, help drive innovation on the web.”
> Third, Google saw Chrome as more than just a browser by developing it with rich, interactive web applications in mind. Lastly, it offered tab “sandboxing,” which kept the entire browser from crashing when one website crashed.
...
> And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browser
I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
And if you want to test Safari? You literally have to buy a dedicated piece of hardware for it. You wonder why it isn't tested?
So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
> A few days before Google Chrome launched, Google released a blog post titled “A fresh take on the browser.” The post explained that they were releasing this new browser because they believed they could “add value for users and, at the same time, help drive innovation on the web.”
What Google says, and what Google does are two very different non-intersecting things.
Edit: Google's maps and docs etc. ran just fine in WebKit. What Google wanted was control. What they did with that control we all know. For example, sabotaged Firefox: https://twitter.com/johnath/status/1116871237240852480
> I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
Doubt.
> So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
Funnily how I've used Safari as my primary browser since 2007, and I've been a web developer for far longer than that... and I haven't run into these issues everyone on HN pretends to have.
> And you blame the developer?
Yes, yes I do. Always. Even in the days of IE6 the problem was always with the developer.
> > I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
> Doubt.
For what it's worth, my development profile is similar. I would say that Safari works most of the time, but I get browser-specific failures from it at a noticeably higher rate than Chrome-derivatives.
One memorable one, if you're curious, was triggered because of a minification step. Terser[0] has a special argument `--safari10` to emit code that's supported by Safari. I discovered this argument after running into the bug.
> Terser[0] has a special argument `--safari10` to emit code that's supported by Safari. I discovered this argument after running into the bug.
So the problem is with the tool, not with the Safari it seems. Without an explanation what "non-standard" is about Safari 10/11 it's on the same level as the rest of hand wringing on HN.
> So the problem is with the tool, not with the Safari it seems.
You're making an assumption. I'm not sure where you're getting that. From what I recall, it was common `const` or parameter declarations in nested scopes. Safari was (is?) unambiguously wrong.
The reason for IEs stagnation wasn’t that Microsoft was trying to hold back the web, it was that their domination was strong enough they didn’t see a need to change. So why would they invest in updating it?
The updates came in plugins tied to the Windows platform: ActiveX. Because that strengthened the monopoly, they were pulling the strings and setting the standards, at their own terms. Tie it to operating system versions, tie it to Office, tie it to the next product they want to promote. Whatever they like.
> it was that their domination was strong enough they didn’t see a need to change. So why would they invest in updating it?
Why invest so hard in capturing the web in the first place, then? Their behavior is consistent with a push to keep people on windows as much as possible.
Yes, and as long as that didn’t require updating the browser, they didn’t. Internet Explorer 6 was Microsofts only option for over 5 years. And if Firefox hadn’t trounced them it would have been for much longer.
Not really in my experience as a primary Firefox dev.
It's easy enough to not use stuff like web USB, and in my experience chrome and firefox "get along" while a page (doing more advanced things) not built for safari simply will not work in safari.
The problem with safari is that Apple makes it so you have to use it if you want your site to work on it. Chrome, I can safely ignore.
I also literally can't use safari if I don't have a Mac.
> while a page (doing more advanced things) not built for safari simply will not work in safari.
I've yet to see such a page [1]. And I've been using Safari since 2007
[1] Unless it's built with Chrome's non-standards of course.
Edit: of course there will be pages broken in Safari (or FF) for no reason other than the sheer incompetence of people building them. E.g. we have an internal dashboard page that is literally nothing more than tables and charts. Ooops, "only works in Chrome".
There's also the minor case of nominally open audio and video codecs that Google pushes to device manufacturers on pain of removing access to its services, but even that hasn't affected me, or most people really, that much.
Developers are eating the problems for you because safari support is almost always a requirement.
This is a developer side problem, not a user side one.
> for no reason other than the sheer incompetence of people building them
Safari never breaks, but when it does it's because the developers are incompetent?
The fact it takes a bunch of extra work to support safari (in more advanced cases like graphs and dashboards) is the whole problem. I have every intent to kick safari out of any home game stuff I do.
> You should reconsider your position when your only response is dismissal and insult.
I've been in these threads many times, and it's the same thing again and again:
- Safari is holding back the web! It doesn't. Well, if you think that Chrome is web, then you're entitled to your opinion
- Safari is new IE! It's not. That it doesn't implement the 400 or so APIs a year that Chrome implements is a feature, not a bug. If your site ends up with a "only works in Chrome" badge, that is your new IE
- Chrome split from WebKit three years after WebKit appeared. And the only reason for the split? Well, to do the same thing you accuse Apple and MS of doing: control. And look how well it worked for them. Everything they do is now considered standard and gospel by the gullible masses of web devs.
And so on.
The irony is that it's Chrome that breaks the web often, and badly, but they get a pass because it's Chrome! They have the new shiny APIs!
> I also literally can't use safari if I don't have a Mac.
You should embrace this; this is how the web should be.
I don't mean you need to buy a Mac. Instead, I mean that the web standards effort originally came up out of supporting diversity. There was a wider range of possible clients, on a wider range of "popular" platforms. As developers we had to cater to support diverging capabilities. Progress on API development was slower, but it was more evenly spread out. Today, Chrome lurches ahead of everyone else in terms of API feature count, mostly supporting Google's business aims, and many vocal developers seem to think they should only support one set of capabilities. The slower, broader, way was better, in my opinion.
Yes, exactly. Use APIs that are broadly supported and somewhat settled and agreed upon. There is seldom an actual need to use whatever new thing that just became supported or is only implemented by Chrome… 95%+ of sites and web apps are doing the same old CRUD things that sites and web apps have been doing for decades and work fine with "boring" APIs.
Unless you have the option to use it for your product then the decision is ship a product using just your web developers and have it not work on Safari/iPads or hire iOS developers and build and maintain a completely separate app.
So it's a 6-7 figure cost to your business that could be saved if they supported that.
That's part of the ECMA standards process, and part of some others; progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit on the leading edge of that process, being more willing to experiment. Safari sits on the other end, for better or worse depending on the feature.
> progressing from a certain stage requires a minimum of two major implementations. The chrome team happens to sit
The Chrome team happens to throw something over the wall and ship it to production with no oversight. And sometimes complain that that they cannot hide it behind a flag because people are already using it.
There's no end of people right here on HN who scream bloody murder when Safari (and Firefox) refuse to implement some new Chrome-only API.
> sometimes complain that that they cannot hide it behind a flag because people are already using it
The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. But it's well documented that this is a temporary process, some Chrome visitors you get won't be eligible for trials, and it's not guaranteed that features in origin trials will ship. What are you thinking of where they just shipped something, without an OT?
> The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation.
For something to become a standard they way it's actually supposed to work is for browsers to come up with two independent implementations.
And yet, Chrome frequently ships APIs it calls standard with just Chrome as the sole implementor.
That wasn't the part of your comment I was replying to. You said they sometimes "complain that that they cannot hide it behind a flag because people are already using it", and I was (a) explaining why that's not supposed to happen and (b) asking about where you saw that happen.
Constructible Stylesheets was released despite objections from both Safari and Firefox when it had both badly designed API and an easily reproduced race condition.
WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed)
"this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea. Other chromium-based browsers may want to know as well, via these channels."
Thankfully, there will be a change. At some point.
===
These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.
In both of your examples they're not saying they "cannot hide it behind a flag because people are already using it":
* With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that.
* With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)
> With adoptedStyleSheets they're objecting to making backwards incompatible changes
Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place.
Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it"
I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make changes because you shipped it?
I’m sorry but that’s just not how standards work.
--- end quote ---
> With WebMIDI they're saying they want to do an announcement before making the change.
Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.
I would happily rather that neither of these happen. For safari not to be a buggy mess/work without extra development efforts and for chrome to have real competition enough to prevent them setting a standard.
I will however, take chrome and user choice every single day over Safari's monopolistic crap.
The mere fact it's largely successful by it's nature of being bundled should scream to you how bad it really is.
> I will however, take chrome and user choice every single day over Safari's monopolistic crap.
That's the problem, though: more and more as time goes on, Chrome isn't user choice. Sites that only work with or only perform as expected under Chrome are becoming more and more common. It's becoming a monopoly too, but enforced by developers rather than a platform owner (though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc), and I'm not sure it's really any better.
> though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc
When (mostly) Chrome came up with Web Components, they immedieately re-wrote Youtibe with Web Components v0 (now deprecated). The polyfill for them was infamously slow on Firefox. Just another ooops in a long line of oopses: https://twitter.com/johnath/status/1116871237240852480
I don't have such a problem with browser makers putting their own ideas into their software. If Google wants to put a Flutter runtime into Chrome, great, go ahead. Where things fall apart is when they prioritize these projects ahead of supporting standards upon which they agreed. Microsoft was free to build and support VML back in IE days. The issue I had was that they refused to support SVG which WAS A ratified standard. So Google creating experiments is just that. They're free to build these, evangelize them and bring these to WHATWG, CSSWG or TC39, or whatever other governing body they'd like. They aren't "creating standards" if these governing bodies do not adopt their experiments.
> So Google creating experiments is just that. They're free to build these, evangelize them and bring these to WHATWG, CSSWG or TC39, or whatever other governing body they'd like. They aren't "creating standards" if these governing bodies do not adopt their experiments.
Then why is HN is screaming bloody murder when other browsers don't implement the plethora of Chrome-only non-standards?
I think this greatly depends on your definition of a “professional environment”.
Also, using non-Safari WebKit for everyday testing (will my newest commit break it? should I fix something before I send the PR?) but using the proper Safari for more thorough testing (e. g. before public releases, or when a bugreport can't be reproduced otherwise) is an option too.
To me this is the biggest difference between Safari and IE/Edge. Microsoft provided free VMs that you could download with all supported versions of IE and Edge. So you could test sites and investigate bug reports. With Safari you can't debug an issue without expensive Apple hardware. I was happy to keep my sites compatible with IE and Edge (maybe not constant testing but some manual testing after big changes). However no way I was going to do that work for Apple when they didn't help out at all.
(The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)
Whenever I look at the frontend QA loop vs. the backend at the places I've worked at, I'm glad I work in machine readable, typed, easier to test API land.
It’s ironic that the people who hate dealing with Safari are, though they would never admit it, actually complaining because they resent having to test in more than one browser.
Let’s just throw in the towel now and rename the web to the Chrome Platform.
Seeing that Safari/mac/iOS and Chrome/blink (so also Edge/Opera) are the only game in town adoption wise (FF has fallen way below), how else would it be?
Probably didn't word my answer well: by "Non-browser based bugs" I mean bugs caused by the code of the webpage having logic issues/bugs (as opposed to bugs caused by browser JS issues or CSS/HTML implementation incompatibilities and such). Perhaps "browser-engine-related" would be a better term
So, I read the parent comment as referring to browser-engine-related bugs - things caused by a browser engine behaving differently, not implemented, etc, and not including in his numbers regular webpage bugs due to html/js programmer error.
That would be a helpful process for more people to maybe look into, if it wasn't for the fact that most computers can't even run Safari, as it's not available on their platform, less than 10% worldwide who browse the web are using macOS.
Sure, but what's your suggestion? Load http://192.168.2.24 on your iPhone while you develop on your Windows machine? Seems unlikely this is a better workflow.
You're not wrong (I develop that way as well), but I'd wager that like me you're not neck deep in service workers and WASM and a "compression streams API."
This isn't a Chrome vs Safari issue (Safari is better, of course), it's the fact that browser development suffers from Apple's corporate wall of silence. In this case, devs literally suffering.
I switched to an Internet Explorer-first approach for web development, and it has reduced my problems considerably. In fact, I make my websites assume they will be viewed in a 640x480 viewport.
I'm basically guaranteeing full compatibility with everything, because everyone has to comply with IE's behaviour. After all, I put a "Best viewed in Internet Explorer", this way if it fails, people blame their browser and not me.
1. A genuine (?) Safari bug with the CompressionStream API. (we never learn what the actual bug was, and their bugreport to WebKit was literally just that "hey, our website at URL ... doesn't work" - no minimal reproducible example whatsoever. Lol)
2. An issue due to them relying on a Chromium bug.
3. An issue due to them assuming that OffscreenCanvas will always support both 2D and 3D (WebGL) contexts.
> I assumed it would have parity with the standard <canvas> element. Why wouldn't it? The MDN documentation mentioned nothing about inconsistent availability of contexts.
only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse
It honestly impressive how quickly they get a fix. Sure it take seven days for someone to get to the bug they filed, but from there it's fixed in 12 hours.
The post makes it sound like both Mozilla and Google are better at handling releases, but Chrome has the service worker bug, so I don't know if that's actually true.
I get that Safari is sluggish, at least compared to Chrome and is currently lacking features, but doesn't it seem like they've picked up the pace in the last year or so?
These were just a few issues with the latest version. Similar problems have occurred with past releases for years, and it seems the author is justifiably stressed out over the lack of transparency and never being sure if/when a breaking change is about to occur for customers using Safari.
I've read the standard [0], to be fair there is nothing in there explicitly indicating that some contexts might be unsupported, except the vague "if this does not throw an exception" condition, which is easy to miss.
This is not a good summary of the article. They're aren't mad at the bugs, they're mad at how Apple handles Safari releases (as seen in the very title of the article).
If you read the "how to fix it" section, the fixes are "transparency", "update Safari independently of the OS", "more pre-release testing options", "communication".
Release schedules &c. aside, they have no argument if they're complaining about the Safari team's "communication". The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.
> Release schedules &c. aside, they have no argument if they're complaining about the Safari team's "communication".
You can't put that aside, because it's the entire point!
"The bug is fixed in the git repository, but we refuse to tell you if or when the fix will appear in Safari" is communication, but it's not the kind of communication needed for web developers.
> The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.
> You can't put that aside, because it's the entire point!
Sorry I didn't mean to imply it wasn't relevant, merely that I wanted to address one small sub-point of your comment.
> is communication, but it's not the kind of communication needed for web developers.
That's fair, but it's relative: a quick response with a commitment of work (if not of timelines) & active dialogue on debugging efforts (due to the complete lack of effort on the part of the reporter) is a LOT better than no commitment or response, or a "please provide more info" / "WONTFIX" / CNR. Which is much more common.
Particularly given I think a "please provide more info" would've been a perfectly reasonable response to the first report.
I understand they're annoyed, but "hell"? Chrome put me through a wild goose chase somewhere around version 94 with some non-standard behavior, and Safari 16 has some weird issue with requestAnimationFrame, but "hell"? That's out of proportions.
If you think this you haven't read the linked bug reports.
His second one in particular is his app relying on unspecified implementation quirks - the Safari devs are responsive due to a desire to be more compatible with Chrome's quirks, not because they've failed to conform to spec.
His first bug report is just lazy and devoid of any detail - completely relies on the Safari team to do the work of debugging his app for him.
I credited the Apple developers with doing a good job in the blog. The point is Apple's policies end up turning what should be a routine bug fix in to a total nightmare.
I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.
Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work, they are used to it.
If possible you should have automatic tests that you can run automatically in several browsers.
Some browser need to be the first one to implement new functionality, before there is a specification! Then the specification comes and often it's different then the already implemented API.
You should not complain about new features, and you should not complain when browsers follow specifications. Instead you should have tests, and encourage users to report problems.
Most browsers have a beta/review release, you can run your test on that, once per day, automatically. Use a program that automate mouse movements and clicks, for example Puppeteer for automating Chrome. (tip: also do performance test while you are at it, so you will know which changes affect performance)
> Most browsers have a beta/review release, you can run your test on that, once per day, automatically.
A large part of the post's complaint is that not only does Safari not have a nightly build, but they don't even give advance notice of when their "technology preview" (beta) or stable releases are coming.
Chrome, by contrast, not only has a public schedule, but a public dashboard where you can follow along.
> Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work, they are used to it.
Is there any statistic to back that up that safari users first blame their browser and switch to a different one before they give up on a site? And why are they still using safari in the first place if it happens so frequently that they made a habit out of switching browsers? I'm not convinced.
> Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work, they are used to it.
I haven't found that to be entirely true. Users will definitely have multiple browsers installed but that's usually because someone in their IT department had them install a second browser for testing. Most users will use one browser the entire time and need someone to tell them to try it in another browser if it's not working.
This is also my experience, but people do tend to migrate to a different browser entirely if their workflows don't work in the other browser.
If every website works in Chrome and most websites work in IE, users will switch to Chrome. Same with Safari. If the thing you're building is interesting enough for users to return to it, the unsupported browser may just stop getting used all together, especially if multiple sites break at the same time (i.e. when Safari broke WebAssembly support).
We encountered a relatively major regression during the iOS 16.4 beta which unfortunately went live with the release version of 16.4. Requesting an 'environment-facing' camera using getUserMedia now provides the ultra-wide camera (rather than the usual standard angle lens). The workaround is unfortunately rather gnarly - having to rely on an order in a list that's not guaranteed by the spec and indeed different on Android.
https://bugs.webkit.org/show_bug.cgi?id=253186
While it's fixed in webkit, the webkit team were unable to tell us if the fix would be in the shipping version of 16.4 and, despite discovering and reporting the bug before it even hit a beta, the shipping 16.4 has the bug.
I really feel for the team who are maintaining the code. It's clear they do a great job in difficult circumstances and it's several high-level policy decisions at Apple make things really challenging for them: they're unable to talk about when bugs and their fixes will (or will not) be present in release software; and Safari updates are tied to OS releases.
It's the dumbest policy, and it's not limited to WebKit: you see this in other open source projects like Swift and LLVM too. As a general policy, Apple does not allow their engineers to talk about future products. When the commit that just landed into the main branch will ship on user's devices falls under "comments on future products" and thus they won't talk about it.
This is the backwards 80s and 90s corporate culture of a secrecy instead of community or customer oriented. Heck, even Microsoft is getting this right nowadays. Apple is one of the most developer hostile companies still standing.
But I guess they will stand until there is external pressure to force them to change e.g. in the form of regulation allowing to bundle alternative web browser engines and not giving preferential private APIs.
When I was working on open source at Google this was also something we had to be very careful with: you don't want to make promises you can't keep. But this wasn't as strict as what Apple does, and vague estimates were allowed.
For example, here's what Chrome does: https://chromiumdash.appspot.com/schedule. All the dates are tentative and sometimes slip, but an engineer can point people to it, say "fix X made the branch cutoff for release NNN", and you can get a pretty good prediction for when X will get to what sort of devices.
Yeah, to be clear, people make jokes about Apple being unable to confirm that there will ever be another iPhone. They're funny because they're mostly true.
Well, you have to understand: the current iPhone model is a perfect pinnacle of technology, so talking about someday releasing something even better would be blasphemy until they actually manage to pull it off...
We've had a similar constraint issue on getUserMedia where it will return the lowest possible resolution for video by default instead of something more pedestrian. Setting exact constraints never seems to work correctly either. Ideal gets closer.
It took us over a year to realize this was the root cause for 2D barcode scanning issues - we had an information-theoretic failure mode due to the low resolution.
Fyi I don't think this issue is limited to Safari, I've seen the exact same problem in some third-party apps which, as far as I can tell, look and feel native.
Safari is the last non-evergreen browser. As long as Apple insists on this policy it doesn't matter how good a job the WebKit team are doing; they're still hamstrung by the outdated release policy Apple enforces.
Luckily, soon Apple will be forced to allow alternative browsers. At that point, I hope Apple will spend some of its trillions on actually improving Safari, in order for it to stay relevant and competitive.
> actually improving Safari, in order for it to stay relevant and competitive
Safari seems to be the last bulwark against a Chrome-only web driven by features of the week.
Full Chrome/Chromium on iOS could very well end that, and I'm not thrilled at the prospect.
Personally I appreciate Safari's resistance to constant featurism in general, and conservative approach to features that are likely to compromise power usage or privacy. I have little desire for web apps to reach complete feature parity with native apps, or to have complete access to all hardware and OS features. Many developers may hate it and want to usher us into Google's PWA future, but I'm absolutely fine where things are right now. And I certainly don't want to have to use Chrome/Chromium for everything.
Lastly, as a developer, I don't like building on quicksand. And yet that's often what it feels like using web/JavaScript frameworks and browsers that change from week to week.
Nonetheless, OP's recommendation that Apple note which versions of Safari a certain bug is fixed in seems like a very good idea that should be adopted.
Frankly, I don’t think all that matters. Safari doesn’t keep up with web standards. It’s not like they’re failing to be competitive as with browser features — that’s a different question. As long as a web standard is specified, and Safari doesn’t implement it, it’s not doing their one job as a browser engine.
The pace of change in the frameworks world is completely independent of web and browser features. And the web is very backwards compatible — so new web platform features don’t rot the foundations of any existing web apps, assuming they use specified features.
> Safari doesn’t keep up with web standards (emphasis yours)
Just pause for a moment and think who's proposing these standards. The same groups pushing for browser "featurism" sit on the committees that define these "standards". It's not meaningful to say that they're different things when they're all part of the same effort in different disguises.
This does match up with my experience pretty well.
Hopefully once the EU forces Apple to open up their app store I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
They you'd lose me as a user. For me as a user Firefox is a terrible browser, it doesn't integrate well with the OS (e.g. no iCloud Keychain) and feels clunky but most importantly: I don't trust Mozilla. In the past they have on multiple occasions shown poor judgment [1][2][3] where they obviously prioritise making money over the interests of their users.
For me, Safari is het only browser I truly trust, because Apple makes money from selling me stuff, instead from selling me.
It's alright if you prefer the way Safari works, but I wouldn't "trust" any browser. I certainly wouldn't only trust the browser made by a company that complies with 90% of government requests for account access: https://www.apple.com/legal/transparency/us.html
A trustworthy browser holds itself accountable by making it's code transparent and it's intentions clear. Mozilla is terrible at marketing Firefox, but I'd argue they've built a much more amicable framework for the web than Apple has.
To be quite honest, I don't care. I'm just a single guy working in his spare time; I don't have the resources to keep up with a trillion dollar corporation.
I'm so done with the endless Safari-only hacks. I'm so done with having to push emergency updates because Apple decided to suddenly break half of my website in the newest version of Safari. And I'm so done with having to explain to my users that, yes, audio autoplay doesn't work on Safari, and no, it's not a bug, it's because Apple actively blocks it and won't let you decide for yourself if you want to enable it for my site, and all of that because they want to force me to build a native app (where I can autoplay to my heart's content) so that they can extort 30% of my income.
> where they obviously prioritise making money over the interests of their users.
...and Apple doesn't do that?
> because Apple makes money from selling me stuff, instead from selling me.
And I hope they don't have to. Opening it up will move the entire web environment to Chrome, and Google's dominance.
> I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
What do you need from a browser that Safari doesn't support? In my experience, everything except obvious bugs has an easy work-around that is supported by the other platforms.
> What do you need from a browser that Safari doesn't support?
For me: a download for Linux or Windows so I can test with the browser. A macOS VM, like Microsoft used to provide for IE development, would also be acceptable.
All my personal projects and even professional projects haven't supported Safari for this very reason.
I'm so happy I don't develop anything that targets web browsers or web servers. Yes deployments are a pain instead, but at least it's a known pain. Package the app and send it off.
In the job I'm currently in (doing front-end for the first time in many years) I can confidently say that every time we've had a bug that was browser-specific, that browser was some brand of Safari - usually Safari mobile, which shits me even more because the iPhone doesn't let users install any alternatives, i.e. literally what Microsoft went to court for. Reason enough on its own not to get an iPhone, or indeed any Apple product at all. I can only imagine how much Safari has cost the industry in wasted dev time.
Microsoft went to court over that because they were leveraging their OS monopoly into a browser monopoly. Microsoft always let you install alternatives by the waybut IE was the default and most people don’t change defaults.
Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure.
Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.
I knew this bit of false internet lore was going to come up.
Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.
> While there were early signs that the browser ballot screen was influencing browser usage in the EU, with Mozilla attributing some European Firefox growth to the selection page, long-term trends strongly suggest that it was next to useless. In spite of equally prominent placement on the selection screen, Opera's share even within Europe appears to have declined over the last five years. So too have Firefox and Internet Explorer. Chrome, however, has experienced significant growth.
Not sure where that number comes from. [1] indicates Apple broke 50% for the first time ever in Q3 2022. I doubt they’ve pole vaulted to 60% the past few quarters.
let f = document.createDocumentFragment();
f.appendChild(document.createElement("div"));
f.firstChild.outerHTML = (`<a href="https://bugs.chromium.org/"></a>`);
Fails because a fragment "is not an element node", a completely bogus error. No idea if it fails in Safari, too, since I don't have a Mac anymore, but I'd guess so, since this reeks of the type of corner-cutting that WebKit was guilty of while swimming in accolades for being a fast, standards-compliant browser engine (in contrast to e.g. Gecko).
> How is it bogus? outerHTML is an attribute of Element
Re-read what is written. I'm setting the outerHTML property of an element, not setting it for the fragment (which is the only way that your response would make sense).
> Have you considered that it's just a Gecko quirk that it happens to work in Firefox?
No, because I'm not a moron.
> Where do the standards say it ought to work?
Exactly where you'd expect to find it: in the specification of the outerHTML property (Leithead et al. DOM Parsing and Serialization, Extensions to the Element interface, §7.1 Attributes: outerHTML. 2016.)
See the Notes section of the docs: "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will also throw an exception." https://developer.mozilla.org/en-US/docs/Web/API/Element/out...
The div has a parent node but no parent element, because a document fragment is not an element.
The standard says that if the parent node is a DocumentFragment, then a temporary Element must be created to act as the context element for fragment parsing [0].
Well, if Mozilla's own web developer API documentation contradicts the spec here, then I'd say that none of the browser vendors are doing on good job on this particular issue.
It's documentation. It's describing the Blink/WebKit behavior and couching it in terms of what "many browsers" do—it's not saying what they should do; all you've done is linked to a page that says the bug exists. Nice try moving the goalposts, though.
It has been a monumental waste of energy participating in this conversation.
That's not quite what it says; it says that (unconditionally) it will do nothing without a parent element and (conditionally, depending on the browser) it will throw an exception. The first part is inaccurate, since the standard behavior (which is the current behavior of Gecko and the intended behavior of Blink) is to let it work naturally on children of DocumentFragments. It should probably be updated to clarify this, but I wouldn't see the remark as very "normative" in the first place.
I just don't see how you interpreted the remark in the way you did. Regardless, I've filed a PR to make the docs clearer [0] so neither of us has to waste any more time on this.
Well, it literally says, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will also throw an exception." I interpret this as, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will throw an exception [on setting an element's outerHTML property if it has no parent element]."
This contains two independent statements, (a) "If the element has no parent element, setting its outerHTML property will not change it or its descendants," and (b) "Many browsers will also throw an exception [on setting an element's outerHTML property if it has no parent element]."
Statement (b) is true, since Chromium- and WebKit-based browsers will throw an exception if the element doesn't have a parent node which is also an element. Statement (a) isn't browser-specific, and thus it is false, since on Firefox, setting an element's outerHTML will change it and its descendants if its parent node is a document fragment (which is not a parent element).
Where we differ might be that I don't see the "many browsers" qualification as applying to the first statement.
The wording has not changed since the 2016 version of the DOM Parsing and Serialization standard [0]:
> On setting, the following steps must be run: 1. Let parent be the context object's parent. [...] 4. If parent is a DocumentFragment, let parent be a new Element with
> - body as its local name,
> - The HTML namespace as its namespace, and
> - The context object's node document as its node document.
But Blink instead throws a DOMException with name "NoModificationAllowedError" and message "Failed to set the 'outerHTML' property on 'Element': This element's parent is of type '#document-fragment', which is not an element node." This was filed as a Chromium bug last December and assigned a week later [1].
Laughable take. When there was only IE6 people complained. Now that there is more than one people complain that they have to test their stuff more and wish to go back to one browser to rule them all. You don't like testing? How hard can it be to test on the top 3-4 browsers? Maybe it's not wasted dev time, it's called work? Maybe software industry isn't for you... Sidenote: Why so many snowflakes on HN? Too much entitlement or is it the easy money? In what job is it considered acceptable to not test on half the devices in the world?
These bug reports are very poor, with apparently no effort to zoom in on the underlying issue, but the WebKit team took application-specific problems like “can’t open project”, “the app gets stuck in the loading screen”, dug in and fixed them in days time. This is stellar support for a single company or product, props to the Safari team for that.
I do agree releasing a broken implementation is bad, not clear what happened there. Aren’t Safari releases held back until a TP is free of critical issues? Was this not marked as critical due to being reported as an app issue instead of a Compression Streams or Service Workers incompatibility / regression?
It is so on macOS. In fact, macOS updates now ship in lockstep with iOS releases.
This is because they all share code, and more importantly, security vulnerability fixes.
You might be referring to how Safari is updated independently of macOS on the 2 non-latest versions of macOS. But those are still released simultaneously with the OS updates, and Safari on the latest version of macOS is bundled with the OS update.
I think I might be referring to that? Mainly referring to the separate “Other Updates” section of downloads, but I didn’t know those are still tied to OS updates for Safari.
See for example how there's a Safari 16.4 update for Big Sur and Monterey but not for Ventura. That's because the macOS Ventura 13.3 update includes the latest Safari, just like the iOS 16.4 update includes the latest Safari. https://support.apple.com/en-us/HT201222
The separate Safari updates are only for back support of older macOS versions.
Given the diligence of the Safari team - especially in the face of the extremely lazy first bug report - it's kinda wild that this person thought it appropriate to post such a negative angle.
The second bug report wasn't even a bug: Chrome & Safari had implemented an unspecified part of the spec. differently to each other (specifically the implementation behind generating client IDs for fetch events in web workers -vs- the main window). The op is relying on an unspecified implementation detail for their app to work. Yet the Safari team actively treat it as a bug in an attempt to be more generally compatible with Chrome.
My takeaway from actually reading through the content of the post is that the Safari devs are responsive and approachable, even even the bug reporter is lazy. Which is more than can be said of many other browsers projects.
I credited the Apple developers with doing a good job in the blog. The problem is Apple's policies end up turning a routine bug fix in to a total nightmare.
I think the larger issue is that you're relying on new or exotic browser APIs without enough skepticism about their behavior across a range of platforms. CompressionStream is brand new in 16.4, so zip.js should absolutely NOT assume it's available, and if it does detect the API, it should gracefully fall back to the older implementation if it encounters errors. I realize this is not your issue, but a dependency—but it could be a reason to use a library with a less aggressive upgrade philosophy, such as Pako.
Author of zip.js here, the CompressionStream API is available for 3 years in Chromium-based browsers [1]. That's why I integrated it 6 months ago in zip.js. However zip.js can detect if the API is present or not, and can work if not available (e.g. in Firefox). It cannot detect implementation bugs in the API though. Note that there's also an option to disable the use of the API [2].
It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it. And you absolutely CAN and should detect implementation bugs in the API. At the very least you can throw CompressionStream's entire compression/decompression process behind a try…catch block, and fall back to the older method on an error.
It was hard for me to anticipate that Apple would implement the CompressionStream API incorrectly 6 months later. However, it is extremely likely that an exception was indeed raised when this bug was triggered. I was never made aware of the existence of this bug. Besides, zip.js does its best to rely on fallback implementations in case of errors. I'm not supposed to integrate the entire CompressionStream API test suite (and all the other APIs) into zip.js either.
> It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it.
As an author you have two main options:
1. Feature detection: check to see if the API exists in the browser, and gracefully fall back if not.
2. UA-sniffing: use the API only on browsers where you've verified that your program works correctly with its implementation.
There's pretty strong consensus on the web that authors should be doing (1), and that (2) is harmful to minority browsers. Every time someone says "the new feature works fine in Firefox if I set my UA to Chrome" they're complaining that the site didn't go with (1).
Yes, using (1) means trusting browsers to get their implementations correct, but they are usually very good about this and getting better. The http://wpt.fyi tests have been a big help here.
I don't disagree with any of that, but you have another option:
0. Wait: Don't adopt the API at all if it is only supported in Chromium, because it's highly probable that the API will have behavioral or API differences if it's implemented by other browsers in the future.
Please read the documentation of the API and you might think the probability would be very low [1].
Note also that zip.js works totally fine in all stable browsers, Safari 16.4 included. There are no known issues [2]. I have absolutely no idea what we are talking about because it looks like the bug has been fixed by Apple in the stable version of Safari. And maybe zip.js helped them to do so.
Waiting doesn't work when Apple do things like ship a working and spec-compliant WebAssembly API which works great so you start using it, then they completely break it in a subsequent update, and leave it both enabled and broken for months. No amount of foresight or caution will save you in that case. It's ultimately the browser maker's responsibility to make sure APIs work.
Chromium-based browsers make up a large portion of many people’s marketshare. It absolutely makes sense to use APIs that are available in them and then polyfill the feature with “the old way” if you feature-detect that it isn’t there.
If browser vendors are releasing the feature unprefixed, that is their signal that they view the feature as stable. It is the responsibility of the browser vendor to ship unbroken features and use vendor prefixes to unambiguously mark if something isn’t fully baked. It is not the responsibility of developers to stick their finger in the wind and try to divine when a feature has subjectively “reached stability”.
Actually, the developer's primary responsibility is to deliver working software to their client or customer.
If you ship a bunch of features based on an assumption about how browsers "should" implement an API in the future and it breaks, you can't tell your customers "it's the browser's fault!" Regardless of what's "fair," it's your software that looks broken. So you can navigate that however you want. I choose not to adopt single-vendor APIs for this exact reason.
> you can’t tell your customers “it’s the browser’s fault!”
Indeed you can’t! Which is the core of my argument for why we also need to be able to properly UA-sniff browser versions. If browsers aren’t holding up their end of the stability bargain, they need to give us a way to version-detect and handle the problem on our end.
Right now what’s pissing me off about Safari is that with their left hand they’re delivering buggy implementations of standardized features and with their right hand they’re cutting off our ability to detect which version of their browser we’re running in (and soon, no doubt, whether we’re running in Safari at all).
I'm not unsympathetic, but I would quibble with your use of the word "standardized" here. Just because one vendor is pushing an API through the standards process does not mean it is "standardized."
Browser makers always recommend feature detection (i.e. use a feature if it's available) over hacks like user-agent sniffing to selectively enable features. Web developers can't look in to a crystal ball and pre-emptively code around APIs with unexpected issues.
I was gonna say then how are you developing for iOS, but this is a website, so you’re right, it’s kinda ridiculous. OTOH if you’re a large enough website you should be testing on every platform.
"Most powerful" phone runs out of memory, but 10 year old Android can handle same site fine. It was working fine in iOS 15 also. And works even in old IE11.
Every iOS release is horror, what will be broken again...
Yes, I am angry and tired of Apple's lack of QA. Trillion dollar company should invest more in quality.
It's not limited to Safari. I used to work on a macOS desktop application, and we used to beg our customers to put off upgrading to new macOS versions to buy time to sort out all the undocumented behavior changes.
"Epiphany Technology Preview" is a WebKit build available for Linux which has been very helpful for testing Safari quirks without having macOS available.
Apple would certainly benefit from more transparency in these matters, no question. Decoupling Safari updates from OS updates and better communication/tracking of issues and release dates would be a big help
At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.
I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.
Yes, and it's a little reckless to even get to a state where, even in the presence of bonafide bugs re non-standard behavior, just showing "a blank screen" when your app dies is a possibility. Add some basic error detection/reporting.
We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.
> It's a shame that browsers don't have to undergo strict compliance tests
There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.
It's also worth noting that Apple has the bad habit of discontinuing Safari Technology Preview support on older macOS versions faster than they discontinue Safari support on older macOS versions, which results in testing gaps for Safari on those versions.
Safari supports the last 3 macOS versions, while Safari Technology Preview only supports the last 2. Take a wild guess which macOS version gets the most new regressions from new Safari versions.
Other than the CompressionStream API bug, the rest of these could have been avoided by a) not relying on a supported 3D Offscreen Canvas and b) having unit tests so you aren't running prod against a Chromium bug.
I understand the stress, but why do they think their product deserves more of Apple's attention than Safari's own product team who undoubtably are working to hard deadlines?
This felt like a really, really long whine because they didn't account for certain issues, and I found the 'Apple employee' references to be a little crass
Sure, mistakes happen, and sometimes it's our fault. But the point is Apple's policies turn what would normally be a routine bug fix in to a total nightmare.
The suggestions as to what Apple could do to help are all great, but it does look (from here) like there could be ways to tweak application development process to better shield against breakage.
It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases.
I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier?
The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library.
The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour?
The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but…
… the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined.
It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.
Ahh, that's your problem right there, man. Apple don't change for you, for me, or for anyone who isn't called Tim Cook. They'll be out there doing their monopolistic, zero-sum, winner-takes-all, my-way-or-the-highway, straight-outta-the-'90s thing, forever and ever.
Apple doesn't care about developers really, as far as the company is concerned they're all little sharecroppers on Steve's garden. Any help you get you should be thankful for, because you have no rights there and never will have. Enjoy your Stockholm syndrome while it lasts.
Why would they care about developers? They care about their customers. People buy their stuff and you, as a dev, have to support Safari. Whether you like it or not. It's called work.
In general, I much prefer Safari to other browsers (though Firefox is generally quite good too). However, I've been bitten by what appears to be a WebKit bug in the latest update: using -webkit-mask-box-image to mask a div with an SVG shape no longer seems to respect the other sub-settings for that property, resulting in the mask being, at least for my use case, repeated 4 times within the space that it is supposed to show once.
I'm still investigating whether this is something that's actually changed with the not-exactly-spec for this WebKit-specific CSS property, but given the behavior I've already observed when trying to debug it, it certainly seems like a regression.
A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari. After 16.4 came out you could check if it worked, and remove the patch at your own pace.
Re: The release timing/schedule problem, I agree that more transparency on the release date would be nice, but since it is tied to an entire OS release, they probably can't do that. The way to go is to keep an eye out for the beta release cycle of iOS. They will typically release 5 or more betas, and then one or more RCs, and then a GM, and then will start rolling out the update to users. There are several websites like Mac Rumors, Apple Insider, 9to5Mac where you can get a good temperature of where in the cycle Apple currently is.
To piggyback off the beta release cycle, I really like Thinky Bits chart on iOS beta releases. Looking at it gives a pretty good idea of when the current beta will hit RC.
> A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari.
IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec.
> After 16.4 came out you could check if it worked, and remove the patch at your own pace.
Great for regularly updated web sites but if you're making a tool you don't want to maintain it'll forever be stuck in a state where Safari performs worse because it isn't using the correct API. And that sucks for users.
> IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec.
In this case I would probably add an "if Safari >=16.4 then skip compression streams" check, but that check would probably still be there in a couple of years. Resolving the immediate issue of "the product doesn't work on Safari" gets priority but "let's see if Safari got their shit together" would be a low priority task for me.
There bad (or seemingly incomplete) spec implementations are how you end up with "your browser is not supported" plastered all over web apps. When Blink will inevitably hit iOS, Apple will have to do a better job placating web dev concerns if it doesn't want to lose market share.
Following the official instructions*, I'm able to run (on iDevices tied to my Apple developer account) a custom built Chromium binary that is supposed to be Blink on iOS. Unfortunately this doesn't seem to be the case, according to a JSFiddle for WebTransport **. Desktop prod Chrome is able to see the WebTransport variable, Desktop prod Safari is unable to, mobile prod Safari is also unable to, and my custom Chromium binary, with use_blink set to true is also unable to. My guess is that my build is not actually reading that flag, but someone more adept at this bespoke build system would easily be able to figure out what's going wrong.
281 comments
[ 2.7 ms ] story [ 269 ms ] threadI sympathize with those who still do and I'm looking forward to EU regulations to allow other rendering engines.
It's clear that they're still trying to undermine the web where possible, without it seeming too obvious or getting them into hot water re: the recent monopolization debate.
- Apple doesn't want others to dictate their development schedule.
- Some Web standards clash with Apple's privacy promises.
While I'd like Apple to do a bit more about those long standing bugs, I think the narrative they are actively undermining the web is short sighted. I prefer Apple's behaviour instead of Google's behaviour to actively monopolise the web...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
---
As a tangent. If it was Apple of, say, 5-10 years ago, I'd also root for them to get their head out of their ass and lead in https://open-ui.org/ (started, of all people, by devs from Microsoft). Alas, with the way they approach interfaces these days, I'd want them far away from leading :)
Webkit is releasing more often and closer to the standards now than they used to. I'm guessing Apple knows they will be forced to allow other engines on iOS and are finally making Safari a good product.
I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance.
I hope the C-level exec at Apple sees this and realises why more devs are going to go with Edge (lol) / Firefox support: the sales guys are running Apple now.
I mean, I don't think it's even close to beign modern day IE. Perfect? Far from it but definitely not as much of a pain as IE
It was not just that IE was broken in all sort of very odd ways, or that it was incompatible with the rest (and standard), or that it was essentially a monopoly.
It was all three. So a site built for IE would not work at all in other browsers if it used anything remotely advanced (and advanced back then was users events), you had to support IE to live (on anything but demo site), and doing so was hell on earth because the bugs went from top to bottom (the browser’s memory management had to be worked around, and there were no memory profiler, hell the debuggers only worked half the time).
Not that it’s any fun encountering a buggy browser, even less so when a feature is so broken you’d be better off if it were not supported and just did nothing or used a fallback and you now have to coerce it into that, and it does seem to be a recurring issue of safari.
But it’s no IE, at this point you’d need malice aforethought to get there.
This is the endgame of a monopoly. Other people start demanding others stop fairly competing with you.
I'd like to think I'm a competent dev.
I use Safari as my daily driver because the difference in performance/battery life on Apple silicon is worth whatever small incompatibilities I run into. It just doesn't ever impact me on a day-to-day basis in the way that performance and battery life do.
Good engineering is all about trade-offs and this is one that doesn't even require a second thought for me.
What also is cool in Safari is to zoom into a page so that everything gets bigger which makes it easier to read text or view pictures (not sure if this is the normal zoom a site has, or something on top OS wise). But a lot of sites are breaking that behaviour now, which results in either not being able to zoom or elements overlapping in weird ways, text not staying where it should. I wonder what CSS stuff is used there.
I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.
There's an important and cool concept here about using the weakest link sometimes.
Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have.
If my app runs well on my iPhone 8, it's obviously going to scream on a 12.
Ah the sweet nectar of naivety. Godspeed to you.
Can't believe I've been a webdev 15 years. What's old becomes new, except for me that is....
https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
1. IE6, a titanic that that wants to harm the web so they can push their own ecosystem instead.
2. IE11, the incompetent and rarely updated browser that you have to support because a segment of your userbase is stuck with it.
This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role. Ensuring apple gets their app store cut.
2 is also the case, but that needs less argument.
What a retcon.
> This article tries to argue 1 isn't the case, but I have to disagree. Safari isn't as large as IE6, but it regardless tries to fill the same role.
Of course it doesn't
> 2 is also the case, but that needs less argument.
It needs as much argument, if not more.
The primary reason for chrome being developed in the first place was to push the web into a place that stuff like Google maps, docs, and so on could exist at all.
> It needs as much argument, if not more.
Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
Retcon again.
> Read this thread where people talk about their experiences developing for safari. Read any open source web libraries issue list. It will be immidiately apparent that safari is the odd man out who constantly has to be baby sat in order to work properly.
And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browsers, and want Chrome-only non-standards delivered yesterday to every browser.
To quote again, "But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."
> The reason I said it needs less argument is that I assumed it would be immidiately apparent. Most people who do web dev come away with this impression.
I do web dev, and it is definitely not immediately apparent.
After IE6 achieved it's goal of destroying the competition, Microsoft literally disbanded the development team. Why would they do that for a very successful product? Because the web didn't have potential?
Firefox started innovation back again a bit, but it took chrome and Google's want to applicationize the web to really kick us into gear.
https://www.androidauthority.com/google-chrome-history-10256...
> A few days before Google Chrome launched, Google released a blog post titled “A fresh take on the browser.” The post explained that they were releasing this new browser because they believed they could “add value for users and, at the same time, help drive innovation on the web.”
> Third, Google saw Chrome as more than just a browser by developing it with rich, interactive web applications in mind. Lastly, it offered tab “sandboxing,” which kept the entire browser from crashing when one website crashed.
...
> And then when you actually read what people are saying, it turns out they only develop on Chrome, couldn't be arsed to develop for or test on other browser
I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
And if you want to test Safari? You literally have to buy a dedicated piece of hardware for it. You wonder why it isn't tested?
So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
You have to buy extra hardware to test on it.
And you blame the developer?
What Google says, and what Google does are two very different non-intersecting things.
Edit: Google's maps and docs etc. ran just fine in WebKit. What Google wanted was control. What they did with that control we all know. For example, sabotaged Firefox: https://twitter.com/johnath/status/1116871237240852480
> I develop for Firefox. Chrome basically always works fine with my pages. Safari chokes on all of them.
Doubt.
> So here's a browser that fails to just work, even when you primarily use Firefox to build the page.
Funnily how I've used Safari as my primary browser since 2007, and I've been a web developer for far longer than that... and I haven't run into these issues everyone on HN pretends to have.
> And you blame the developer?
Yes, yes I do. Always. Even in the days of IE6 the problem was always with the developer.
> Doubt.
For what it's worth, my development profile is similar. I would say that Safari works most of the time, but I get browser-specific failures from it at a noticeably higher rate than Chrome-derivatives.
One memorable one, if you're curious, was triggered because of a minification step. Terser[0] has a special argument `--safari10` to emit code that's supported by Safari. I discovered this argument after running into the bug.
[0]: https://github.com/terser/terser
So the problem is with the tool, not with the Safari it seems. Without an explanation what "non-standard" is about Safari 10/11 it's on the same level as the rest of hand wringing on HN.
You're making an assumption. I'm not sure where you're getting that. From what I recall, it was common `const` or parameter declarations in nested scopes. Safari was (is?) unambiguously wrong.
Edit: here's the bug: https://bugs.webkit.org/show_bug.cgi?id=171041
The updates came in plugins tied to the Windows platform: ActiveX. Because that strengthened the monopoly, they were pulling the strings and setting the standards, at their own terms. Tie it to operating system versions, tie it to Office, tie it to the next product they want to promote. Whatever they like.
Why invest so hard in capturing the web in the first place, then? Their behavior is consistent with a push to keep people on windows as much as possible.
I mean you know there was a period of time where Safari existed and Chrome didn't.
"Want global web compatibility? Fuck you buy a Mac"
-Apple
Still better than "whatever we throw over the wall is now a standard" that Chrome has, and you can see people clamouring for those on HN.
It's easy enough to not use stuff like web USB, and in my experience chrome and firefox "get along" while a page (doing more advanced things) not built for safari simply will not work in safari.
The problem with safari is that Apple makes it so you have to use it if you want your site to work on it. Chrome, I can safely ignore.
I also literally can't use safari if I don't have a Mac.
I've yet to see such a page [1]. And I've been using Safari since 2007
[1] Unless it's built with Chrome's non-standards of course.
Edit: of course there will be pages broken in Safari (or FF) for no reason other than the sheer incompetence of people building them. E.g. we have an internal dashboard page that is literally nothing more than tables and charts. Ooops, "only works in Chrome".
There's also the minor case of nominally open audio and video codecs that Google pushes to device manufacturers on pain of removing access to its services, but even that hasn't affected me, or most people really, that much.
Developers are eating the problems for you because safari support is almost always a requirement.
This is a developer side problem, not a user side one.
> for no reason other than the sheer incompetence of people building them
Safari never breaks, but when it does it's because the developers are incompetent?
The fact it takes a bunch of extra work to support safari (in more advanced cases like graphs and dashboards) is the whole problem. I have every intent to kick safari out of any home game stuff I do.
The problems "developers are eating" are hugely overblown
> Safari never breaks, but when it does it's because the developers are incompetent?
In 99% of the times? Yes.
> The fact it takes a bunch of extra work to support safari
No, it doesn't. Source: web developer myself.
Of course, if you rely on Chrome-only non-standards, that's a different issue.
> in more advanced cases like graphs and dashboards
Graphs and Dashboards are advanced use cases now. Gotcha.
I've been in these threads many times, and it's the same thing again and again:
- Safari is holding back the web! It doesn't. Well, if you think that Chrome is web, then you're entitled to your opinion
- Safari is new IE! It's not. That it doesn't implement the 400 or so APIs a year that Chrome implements is a feature, not a bug. If your site ends up with a "only works in Chrome" badge, that is your new IE
- Chrome split from WebKit three years after WebKit appeared. And the only reason for the split? Well, to do the same thing you accuse Apple and MS of doing: control. And look how well it worked for them. Everything they do is now considered standard and gospel by the gullible masses of web devs.
And so on.
The irony is that it's Chrome that breaks the web often, and badly, but they get a pass because it's Chrome! They have the new shiny APIs!
You should embrace this; this is how the web should be.
I don't mean you need to buy a Mac. Instead, I mean that the web standards effort originally came up out of supporting diversity. There was a wider range of possible clients, on a wider range of "popular" platforms. As developers we had to cater to support diverging capabilities. Progress on API development was slower, but it was more evenly spread out. Today, Chrome lurches ahead of everyone else in terms of API feature count, mostly supporting Google's business aims, and many vocal developers seem to think they should only support one set of capabilities. The slower, broader, way was better, in my opinion.
Unless you have the option to use it for your product then the decision is ship a product using just your web developers and have it not work on Safari/iPads or hire iOS developers and build and maintain a completely separate app.
So it's a 6-7 figure cost to your business that could be saved if they supported that.
The Chrome team happens to throw something over the wall and ship it to production with no oversight. And sometimes complain that that they cannot hide it behind a flag because people are already using it.
There's no end of people right here on HN who scream bloody murder when Safari (and Firefox) refuse to implement some new Chrome-only API.
The way this is supposed to work is an origin trial: you ship something behind a flag, and then allow sites to flip the flag for testing and experimentation. But it's well documented that this is a temporary process, some Chrome visitors you get won't be eligible for trials, and it's not guaranteed that features in origin trials will ship. What are you thinking of where they just shipped something, without an OT?
For something to become a standard they way it's actually supposed to work is for browsers to come up with two independent implementations.
And yet, Chrome frequently ships APIs it calls standard with just Chrome as the sole implementor.
Literally "Note that .adoptedStyleSheets is used on about ~.8% of page loads in Chrome now. Backwards-incompatible changes are definitely an issue here." https://github.com/WICG/construct-stylesheets/issues/45#issu...
---
WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed)
Well, what do you know https://groups.google.com/a/chromium.org/g/blink-api-owners-...
"this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea. Other chromium-based browsers may want to know as well, via these channels."
Thankfully, there will be a change. At some point.
===
These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.
* With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that.
* With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)
Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place.
Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it"
And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...:
--- start quote ---
I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make changes because you shipped it?
I’m sorry but that’s just not how standards work.
--- end quote ---
> With WebMIDI they're saying they want to do an announcement before making the change.
Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.
I will however, take chrome and user choice every single day over Safari's monopolistic crap.
The mere fact it's largely successful by it's nature of being bundled should scream to you how bad it really is.
That's the problem, though: more and more as time goes on, Chrome isn't user choice. Sites that only work with or only perform as expected under Chrome are becoming more and more common. It's becoming a monopoly too, but enforced by developers rather than a platform owner (though this is muddy with how Google gives Chrome performance advantages in Youtube, Docs, etc), and I'm not sure it's really any better.
When (mostly) Chrome came up with Web Components, they immedieately re-wrote Youtibe with Web Components v0 (now deprecated). The polyfill for them was infamously slow on Firefox. Just another ooops in a long line of oopses: https://twitter.com/johnath/status/1116871237240852480
Then why is HN is screaming bloody murder when other browsers don't implement the plethora of Chrome-only non-standards?
Also, using non-Safari WebKit for everyday testing (will my newest commit break it? should I fix something before I send the PR?) but using the proper Safari for more thorough testing (e. g. before public releases, or when a bugreport can't be reproduced otherwise) is an option too.
(The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)
Let’s just throw in the towel now and rename the web to the Chrome Platform.
https://github.com/microsoft/playwright
Or depending on your tolerance for legal grey areas, you can also download MacOS directly from Apple servers and run it in a virtual machine.
Or if your objection isn’t to paying money but rather paying Apple, you can buy second-hand hardware.
Probably didn't word my answer well: by "Non-browser based bugs" I mean bugs caused by the code of the webpage having logic issues/bugs (as opposed to bugs caused by browser JS issues or CSS/HTML implementation incompatibilities and such). Perhaps "browser-engine-related" would be a better term
So, I read the parent comment as referring to browser-engine-related bugs - things caused by a browser engine behaving differently, not implemented, etc, and not including in his numbers regular webpage bugs due to html/js programmer error.
This isn't a Chrome vs Safari issue (Safari is better, of course), it's the fact that browser development suffers from Apple's corporate wall of silence. In this case, devs literally suffering.
I'm basically guaranteeing full compatibility with everything, because everyone has to comply with IE's behaviour. After all, I put a "Best viewed in Internet Explorer", this way if it fails, people blame their browser and not me.
1. A genuine (?) Safari bug with the CompressionStream API. (we never learn what the actual bug was, and their bugreport to WebKit was literally just that "hey, our website at URL ... doesn't work" - no minimal reproducible example whatsoever. Lol)
2. An issue due to them relying on a Chromium bug.
3. An issue due to them assuming that OffscreenCanvas will always support both 2D and 3D (WebGL) contexts.
only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse
The post makes it sound like both Mozilla and Google are better at handling releases, but Chrome has the service worker bug, so I don't know if that's actually true.
I get that Safari is sluggish, at least compared to Chrome and is currently lacking features, but doesn't it seem like they've picked up the pace in the last year or so?
[0] https://html.spec.whatwg.org/multipage/canvas.html#the-offsc...
This is not a good summary of the article. They're aren't mad at the bugs, they're mad at how Apple handles Safari releases (as seen in the very title of the article).
If you read the "how to fix it" section, the fixes are "transparency", "update Safari independently of the OS", "more pre-release testing options", "communication".
You can't put that aside, because it's the entire point!
"The bug is fixed in the git repository, but we refuse to tell you if or when the fix will appear in Safari" is communication, but it's not the kind of communication needed for web developers.
> The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.
I have to disagree there.
Sorry I didn't mean to imply it wasn't relevant, merely that I wanted to address one small sub-point of your comment.
> is communication, but it's not the kind of communication needed for web developers.
That's fair, but it's relative: a quick response with a commitment of work (if not of timelines) & active dialogue on debugging efforts (due to the complete lack of effort on the part of the reporter) is a LOT better than no commitment or response, or a "please provide more info" / "WONTFIX" / CNR. Which is much more common.
Particularly given I think a "please provide more info" would've been a perfectly reasonable response to the first report.
Standards compliance really is the name of the game, and I wish people like GP had more pull to force Apple to make these reasonable changes.
His second one in particular is his app relying on unspecified implementation quirks - the Safari devs are responsive due to a desire to be more compatible with Chrome's quirks, not because they've failed to conform to spec.
His first bug report is just lazy and devoid of any detail - completely relies on the Safari team to do the work of debugging his app for him.
I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.
If possible you should have automatic tests that you can run automatically in several browsers.
Some browser need to be the first one to implement new functionality, before there is a specification! Then the specification comes and often it's different then the already implemented API.
You should not complain about new features, and you should not complain when browsers follow specifications. Instead you should have tests, and encourage users to report problems.
Most browsers have a beta/review release, you can run your test on that, once per day, automatically. Use a program that automate mouse movements and clicks, for example Puppeteer for automating Chrome. (tip: also do performance test while you are at it, so you will know which changes affect performance)
A large part of the post's complaint is that not only does Safari not have a nightly build, but they don't even give advance notice of when their "technology preview" (beta) or stable releases are coming.
Chrome, by contrast, not only has a public schedule, but a public dashboard where you can follow along.
https://developer.chrome.com/blog/early-stable/
https://chromiumdash.appspot.com/schedule
I don't. If your web site doesn't support Safari then I will take my business elsewhere.
Unfortunately iOS users don't have this option.
Is there any statistic to back that up that safari users first blame their browser and switch to a different one before they give up on a site? And why are they still using safari in the first place if it happens so frequently that they made a habit out of switching browsers? I'm not convinced.
HAHAHA.
Are you not aware that every browser in iOS is basically wrapper for Safari?
New bugs in Safari will break other browsers also.
I haven't found that to be entirely true. Users will definitely have multiple browsers installed but that's usually because someone in their IT department had them install a second browser for testing. Most users will use one browser the entire time and need someone to tell them to try it in another browser if it's not working.
If every website works in Chrome and most websites work in IE, users will switch to Chrome. Same with Safari. If the thing you're building is interesting enough for users to return to it, the unsupported browser may just stop getting used all together, especially if multiple sites break at the same time (i.e. when Safari broke WebAssembly support).
Okay, how do I run headless Safari in a CI exactly? And how do I run Safari mobile in a CI since it has different bugs than the other one sometimes?
I'm sure some people hacked some stuff together with ducktape but you are far far outside the supported development cycle of this software.
Apple literally goes out of their way to deny you the right to use another browser engine on their mobile phones.
Please go and meet some of your users in person and watch them use a computer/phone. Your eyes will be opened to a world you never knew existed.
While it's fixed in webkit, the webkit team were unable to tell us if the fix would be in the shipping version of 16.4 and, despite discovering and reporting the bug before it even hit a beta, the shipping 16.4 has the bug.
I really feel for the team who are maintaining the code. It's clear they do a great job in difficult circumstances and it's several high-level policy decisions at Apple make things really challenging for them: they're unable to talk about when bugs and their fixes will (or will not) be present in release software; and Safari updates are tied to OS releases.
But I guess they will stand until there is external pressure to force them to change e.g. in the form of regulation allowing to bundle alternative web browser engines and not giving preferential private APIs.
For example, here's what Chrome does: https://chromiumdash.appspot.com/schedule. All the dates are tentative and sometimes slip, but an engineer can point people to it, say "fix X made the branch cutoff for release NNN", and you can get a pretty good prediction for when X will get to what sort of devices.
https://whattrainisitnow.com/
https://whattrainisitnow.com/calendar/
It took us over a year to realize this was the root cause for 2D barcode scanning issues - we had an information-theoretic failure mode due to the low resolution.
Safari is the last non-evergreen browser. As long as Apple insists on this policy it doesn't matter how good a job the WebKit team are doing; they're still hamstrung by the outdated release policy Apple enforces.
Luckily, soon Apple will be forced to allow alternative browsers. At that point, I hope Apple will spend some of its trillions on actually improving Safari, in order for it to stay relevant and competitive.
Safari seems to be the last bulwark against a Chrome-only web driven by features of the week.
Full Chrome/Chromium on iOS could very well end that, and I'm not thrilled at the prospect.
Personally I appreciate Safari's resistance to constant featurism in general, and conservative approach to features that are likely to compromise power usage or privacy. I have little desire for web apps to reach complete feature parity with native apps, or to have complete access to all hardware and OS features. Many developers may hate it and want to usher us into Google's PWA future, but I'm absolutely fine where things are right now. And I certainly don't want to have to use Chrome/Chromium for everything.
Lastly, as a developer, I don't like building on quicksand. And yet that's often what it feels like using web/JavaScript frameworks and browsers that change from week to week.
Nonetheless, OP's recommendation that Apple note which versions of Safari a certain bug is fixed in seems like a very good idea that should be adopted.
The pace of change in the frameworks world is completely independent of web and browser features. And the web is very backwards compatible — so new web platform features don’t rot the foundations of any existing web apps, assuming they use specified features.
Just pause for a moment and think who's proposing these standards. The same groups pushing for browser "featurism" sit on the committees that define these "standards". It's not meaningful to say that they're different things when they're all part of the same effort in different disguises.
Hopefully once the EU forces Apple to open up their app store I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
For me, Safari is het only browser I truly trust, because Apple makes money from selling me stuff, instead from selling me.
[1] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo... [2] https://www.theverge.com/2021/10/7/22715179/firefox-suggest-... [3] https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
A trustworthy browser holds itself accountable by making it's code transparent and it's intentions clear. Mozilla is terrible at marketing Firefox, but I'd argue they've built a much more amicable framework for the web than Apple has.
To be quite honest, I don't care. I'm just a single guy working in his spare time; I don't have the resources to keep up with a trillion dollar corporation.
I'm so done with the endless Safari-only hacks. I'm so done with having to push emergency updates because Apple decided to suddenly break half of my website in the newest version of Safari. And I'm so done with having to explain to my users that, yes, audio autoplay doesn't work on Safari, and no, it's not a bug, it's because Apple actively blocks it and won't let you decide for yourself if you want to enable it for my site, and all of that because they want to force me to build a native app (where I can autoplay to my heart's content) so that they can extort 30% of my income.
> where they obviously prioritise making money over the interests of their users.
...and Apple doesn't do that?
> because Apple makes money from selling me stuff, instead from selling me.
Are you sure? https://proton.me/blog/apple-ad-company
> I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
What do you need from a browser that Safari doesn't support? In my experience, everything except obvious bugs has an easy work-around that is supported by the other platforms.
For me: a download for Linux or Windows so I can test with the browser. A macOS VM, like Microsoft used to provide for IE development, would also be acceptable.
All my personal projects and even professional projects haven't supported Safari for this very reason.
It has a kind of distinctive feel of nonsense, I don't know how to explain it.
Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure.
Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.
Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.
https://arstechnica.com/information-technology/2014/12/windo...
> While there were early signs that the browser ballot screen was influencing browser usage in the EU, with Mozilla attributing some European Firefox growth to the selection page, long-term trends strongly suggest that it was next to useless. In spite of equally prominent placement on the selection screen, Opera's share even within Europe appears to have declined over the last five years. So too have Firefox and Internet Explorer. Chrome, however, has experienced significant growth.
Thats only true outside of the US though. iOS is >60% in the USA.
[1] https://9to5mac.com/2022/09/02/iphone-us-market-share/
How is it bogus? outerHTML is an attribute of Element https://developer.mozilla.org/en-US/docs/Web/API/Element/out... and DocumentFragment is not an Element https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...
> No idea if it fails in Safari, too
It does.
Have you considered that it's just a Gecko quirk that it happens to work in Firefox? Where do the standards say it ought to work?
Re-read what is written. I'm setting the outerHTML property of an element, not setting it for the fragment (which is the only way that your response would make sense).
> Have you considered that it's just a Gecko quirk that it happens to work in Firefox?
No, because I'm not a moron.
> Where do the standards say it ought to work?
Exactly where you'd expect to find it: in the specification of the outerHTML property (Leithead et al. DOM Parsing and Serialization, Extensions to the Element interface, §7.1 Attributes: outerHTML. 2016.)
The div has a parent node but no parent element, because a document fragment is not an element.
[0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...
It has been a monumental waste of energy participating in this conversation.
[0] https://github.com/mdn/content/pull/25925
Can you be concrete? (This reply doesn't really clear up anything about the previous comment.)
This contains two independent statements, (a) "If the element has no parent element, setting its outerHTML property will not change it or its descendants," and (b) "Many browsers will also throw an exception [on setting an element's outerHTML property if it has no parent element]."
Statement (b) is true, since Chromium- and WebKit-based browsers will throw an exception if the element doesn't have a parent node which is also an element. Statement (a) isn't browser-specific, and thus it is false, since on Firefox, setting an element's outerHTML will change it and its descendants if its parent node is a document fragment (which is not a parent element).
Where we differ might be that I don't see the "many browsers" qualification as applying to the first statement.
> NoModificationAllowedError DOMException
> Thrown if an attempt was made to set outerHTML on an element which is a direct child of a Document, such as Document.documentElement.
So I'd say the Notes section is simply imprecise.
The wording has not changed since the 2016 version of the DOM Parsing and Serialization standard [0]:
> On setting, the following steps must be run: 1. Let parent be the context object's parent. [...] 4. If parent is a DocumentFragment, let parent be a new Element with
> - body as its local name,
> - The HTML namespace as its namespace, and
> - The context object's node document as its node document.
But Blink instead throws a DOMException with name "NoModificationAllowedError" and message "Failed to set the 'outerHTML' property on 'Element': This element's parent is of type '#document-fragment', which is not an element node." This was filed as a Chromium bug last December and assigned a week later [1].
[0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...
[1] https://crbug.com/1403060
I do agree releasing a broken implementation is bad, not clear what happened there. Aren’t Safari releases held back until a TP is free of critical issues? Was this not marked as critical due to being reported as an app issue instead of a Compression Streams or Service Workers incompatibility / regression?
No. Safari releases ship in lockstep with iOS releases.
This is because they all share code, and more importantly, security vulnerability fixes.
You might be referring to how Safari is updated independently of macOS on the 2 non-latest versions of macOS. But those are still released simultaneously with the OS updates, and Safari on the latest version of macOS is bundled with the OS update.
The separate Safari updates are only for back support of older macOS versions.
Given the diligence of the Safari team - especially in the face of the extremely lazy first bug report - it's kinda wild that this person thought it appropriate to post such a negative angle.
The second bug report wasn't even a bug: Chrome & Safari had implemented an unspecified part of the spec. differently to each other (specifically the implementation behind generating client IDs for fetch events in web workers -vs- the main window). The op is relying on an unspecified implementation detail for their app to work. Yet the Safari team actively treat it as a bug in an attempt to be more generally compatible with Chrome.
My takeaway from actually reading through the content of the post is that the Safari devs are responsive and approachable, even even the bug reporter is lazy. Which is more than can be said of many other browsers projects.
[1] https://caniuse.com/?search=CompressionStream
[2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...
As an author you have two main options:
1. Feature detection: check to see if the API exists in the browser, and gracefully fall back if not.
2. UA-sniffing: use the API only on browsers where you've verified that your program works correctly with its implementation.
There's pretty strong consensus on the web that authors should be doing (1), and that (2) is harmful to minority browsers. Every time someone says "the new feature works fine in Firefox if I set my UA to Chrome" they're complaining that the site didn't go with (1).
Yes, using (1) means trusting browsers to get their implementations correct, but they are usually very good about this and getting better. The http://wpt.fyi tests have been a big help here.
0. Wait: Don't adopt the API at all if it is only supported in Chromium, because it's highly probable that the API will have behavioral or API differences if it's implemented by other browsers in the future.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Compression...
[2] https://github.com/gildas-lormeau/zip.js/issues
If browser vendors are releasing the feature unprefixed, that is their signal that they view the feature as stable. It is the responsibility of the browser vendor to ship unbroken features and use vendor prefixes to unambiguously mark if something isn’t fully baked. It is not the responsibility of developers to stick their finger in the wind and try to divine when a feature has subjectively “reached stability”.
If you ship a bunch of features based on an assumption about how browsers "should" implement an API in the future and it breaks, you can't tell your customers "it's the browser's fault!" Regardless of what's "fair," it's your software that looks broken. So you can navigate that however you want. I choose not to adopt single-vendor APIs for this exact reason.
Indeed you can’t! Which is the core of my argument for why we also need to be able to properly UA-sniff browser versions. If browsers aren’t holding up their end of the stability bargain, they need to give us a way to version-detect and handle the problem on our end.
Right now what’s pissing me off about Safari is that with their left hand they’re delivering buggy implementations of standardized features and with their right hand they’re cutting off our ability to detect which version of their browser we’re running in (and soon, no doubt, whether we’re running in Safari at all).
"a problem repeatedly occurred" and page crashes all the time.
Only in Safari iOS 16. Worked in iOS 15. Works even in IE.
What kind of bug report can you make out of it?
They release new API but they "forgot" to test when website is added to home screen (PWA).
New API passes feature detection but does not work in PWA.
iOS and macOS Safari have different bugs also...
So you have to sniff user agent and other things to find out broken iOS versions and hardcode workarounds...
In either case, there are plenty of browser testing SaaS that give you real Mac/Win/Linux/iOS/Android machines for testing and debugging.
https://developer.microsoft.com/en-us/windows/downloads/virt...
"Most powerful" phone runs out of memory, but 10 year old Android can handle same site fine. It was working fine in iOS 15 also. And works even in old IE11.
Every iOS release is horror, what will be broken again...
Yes, I am angry and tired of Apple's lack of QA. Trillion dollar company should invest more in quality.
https://webkit.org/downloads/
At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.
There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.
It's also worth noting that Apple has the bad habit of discontinuing Safari Technology Preview support on older macOS versions faster than they discontinue Safari support on older macOS versions, which results in testing gaps for Safari on those versions.
Safari supports the last 3 macOS versions, while Safari Technology Preview only supports the last 2. Take a wild guess which macOS version gets the most new regressions from new Safari versions.
I understand the stress, but why do they think their product deserves more of Apple's attention than Safari's own product team who undoubtably are working to hard deadlines?
This felt like a really, really long whine because they didn't account for certain issues, and I found the 'Apple employee' references to be a little crass
It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases.
I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier?
The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library.
The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour?
The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but…
… the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined.
It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.
Ahh, that's your problem right there, man. Apple don't change for you, for me, or for anyone who isn't called Tim Cook. They'll be out there doing their monopolistic, zero-sum, winner-takes-all, my-way-or-the-highway, straight-outta-the-'90s thing, forever and ever.
Apple doesn't care about developers really, as far as the company is concerned they're all little sharecroppers on Steve's garden. Any help you get you should be thankful for, because you have no rights there and never will have. Enjoy your Stockholm syndrome while it lasts.
I'm still investigating whether this is something that's actually changed with the not-exactly-spec for this WebKit-specific CSS property, but given the behavior I've already observed when trying to debug it, it certainly seems like a regression.
Re: The release timing/schedule problem, I agree that more transparency on the release date would be nice, but since it is tied to an entire OS release, they probably can't do that. The way to go is to keep an eye out for the beta release cycle of iOS. They will typically release 5 or more betas, and then one or more RCs, and then a GM, and then will start rolling out the update to users. There are several websites like Mac Rumors, Apple Insider, 9to5Mac where you can get a good temperature of where in the cycle Apple currently is.
http://www.thinkybits.com/blog/iOS-versions/
IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec.
> After 16.4 came out you could check if it worked, and remove the patch at your own pace.
Great for regularly updated web sites but if you're making a tool you don't want to maintain it'll forever be stuck in a state where Safari performs worse because it isn't using the correct API. And that sucks for users.
In this case I would probably add an "if Safari >=16.4 then skip compression streams" check, but that check would probably still be there in a couple of years. Resolving the immediate issue of "the product doesn't work on Safari" gets priority but "let's see if Safari got their shit together" would be a low priority task for me.
There bad (or seemingly incomplete) spec implementations are how you end up with "your browser is not supported" plastered all over web apps. When Blink will inevitably hit iOS, Apple will have to do a better job placating web dev concerns if it doesn't want to lose market share.
* https://chromium.googlesource.com/chromium/src/+/main/docs/i...
** https://jsfiddle.net/jib1/8gtd3s9v/10/