I think it has to do with the update cycle, or lack thereof. The iOS browser gets updated a couple times a year with new minor OS releases, whereas browsers for older OS versions get no updates ever. So if a bug is hardy enough to survive an entire year, it's there to stay.
Given Apple's opaque approach to support, even a good repro case of a bug in an upcoming iOS release is unlikely to ever make it to a fixed shape by the time said OS version is obsolete. So you have to switch for every single OS version, by name, since features are in fact in place, but work inconsistently between versions.
Before typing this, I just finished putting the first few new iOS9 switches into the app I'm developing, resurrecting various things that they killed in the beta. Maybe those switches can come out when they ship the real thing. But that has never happened before, so I'm not holding out any hope.
Apple did introduce XPC in iOS 8 and all the extensions use XPC extensively to respect the sandboxing rules. This is what they used to introduce the WebKitViewController whose JavaScript performance is on part Mobile Safari (UIWebView’s JavaScript performance is poor due to not having JIT). In fact, the new SafariViewController that was introduced in iOS 9, which is effectively an embedded Mobile Safari in third-party apps, is mainly possible because the OS has first-class support for XPC within the confines of the application sandbox.
I could see, although I’m not sure how likely it would be, Apple introducing a new Extension Point for rendering engines. Although it’s attractive to attribute malice to their intentions, I don’t think Apple are actively enforcing the “all third-party browsers have to use WebKit" for any other reason than security and battery life impact. If they could find a way to allow third-party rendering engines/browsers to work within the confines of the application sandbox, be secure and have insignificant impact on the battery life, they would allow it. They’re almost there technically, anyway.
Basically, no vendor wants to put in the work of porting to iOS without the guarantee that it can be excepted in the App Store.
Safari on mobile is crap because it doesn't render like the other browsers do. Just like with IE we are constantly having to do special conditions for those unfortunate souls on iOS Safari. Hence, Safari is the new IE.
I had to make my own buttons as having too many buttons would slow rendering of the page to a crawl. The gradient background was the speed killer.
Doesn't help that you can only remote debug the browser from a Mac.
Make no mistake, I think IE11 is a huge step in the right direction in terms of standards compliance, but right now it's not really usable.
I'd be interested to hear about these hot spots though (if you've blogged about them anywhere?). I've generally been quite pleased with Microsoft's browser effort in the past couple of years. Safari is quickly travelling toward becoming the next IE9 with the kind of weird bugs I've come across recently.
Yeah, not like it has a different engine and the others are required to use a lesser one...
I didn't try to start an argument on Apple sabotaging it's competitors...
Two examples come to my mind: Indexeddb and suddenly changing the behaviour of taps on homescreen apps but NOT in Safari.
It is one thing not having support for a feature, and it is another shipping a broken implementation. Also, there is ZERO communication on if/when a bug will be fixed.
IE only ever had decent accessibility support because it was ubiquitous and third-parties provided a solution.
On this specific cases, I do know that browsers have problems (including Safari, mind you), but people just throw the word "accessibility" around as if it was a specific concept, instead of the actually actionable option of complaining about specific problems. (Who is it that can not access Chrome and Firefox? Is it blind people? People with bad eyesight? People with bad motor skills? Paralytic people?) That has the effect of making your comment just vague enough to be impossible to argue with (however true it is), but still appear specific enough to make people think it has a meaning.
Besides, yes, we should make the world accessible to impaired people. But we also should not make the other 80% of the people hostage of the first group. For some reason, accessibility arguments are almost always claiming that everybody must use the worst alternative because some undefined subgroup of those 20% can't use the better one.
Another aspect is OS specificity, MS has made it very easy to debug IE without having windows via VMs they put out specifically for this purpose. Meanwhile there is no amount of money Apple will accept from you to run a mac vm on non Mac hardware. I have fond memories of trying to debug issues with Web Workers in safari via sauce labs.
(disclaimer, I worked with Nolan Lawson on pouchdb and he credits me with coming up with the safari is the new ie phrase)
Why this is a problem is that it means the web will stagnate. People will do new things, but only within the limits of the old technology. Many of the things Safari lacks are trivial to work around (an input color picker for example .. it's easy to do that in JS). Other things are much more important - picture elements and HTTP/2 being good examples.
As someone who has done Web development prior to and throughout the entire lifespan of IE6, I say: no, no it does not.
I wish the Edge team the best, and hope their application spurs more innovation and improvement in the browser space. But I (like many others) will be burdened with IE support for the foreseeable future, and see no need to temper my strong dislike for the product.
"Burdened with IE support".. surely you don't mean IE6 though?
Since Google started developing Blink for Chrome, it is now getting all the new features, such as CSS will-change, http2, shadow dom, css motion paths, ...
Safari / Webkit isn't anymore the leader. Occasionally, it receives some odd Apple specific features, like masked favicons [1] or force touch events [2].
[1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2...
[2] https://developer.apple.com/library/prerelease/mac/documenta...
1. He's looking at Safari 9, a version that is not yet deployed anywhere, rather than Safari 7/8, which are the versions that everyone knows and loathes. Yeah, if you move the target, then of course some criticisms will miss their mark.
2. Even ignoring version numbers, he's looking at the "best" Safari that exists: desktop Safari. iOS Safari is where the real nightmares are, and is the target of almost all of the complaints about Safari that he's supposedly refuting. Again, when refuting someone else's case, you have to refute their actual case, not an altered, easier-to-fight version of their case.
3. The case he's making is that Safari's not the worst because Edge is worse. Except that Edge is not 100% complete (it's more akin to the early days of Chrome: yes, you can use it, but it's a work in progress), is in fairly-transparent, visibly-active development, and is an "evergreen" (continuously self-updating) browser, unlike Safari, which only gets updated either with the OS or when there's an absolutely-critical-enough security hole.
4. His basis for comparison is number of features listed as "supported" on caniuse rather than standards-compliance, rendering consistency, actual usability of purportedly-complete APIs, and general how-bad-does-this-browser-screw-up-my-app. For example: iOS Safari supposedly supports "position: fixed" (which has been around basically forever), but in practice has significant rendering issues, particularly around when it decides to stop positioning things because the keyboard is present.
5. His initial premise (and, tellingly, his conclusion) is that people complain about Safari because people want to complain and poor Safari just happens to be the current target, rather than that Safari might have some actual problems that make web development painful.
Safari 8 to Safari 9 got +4 points on HTML5test - only adding some canvas2d features and some CSS selectors. IE11 to Edge got +66 points, adding loads of features. MS also have a clear roadmap, and Apple has very little. I think this is contributing to the sense that Safari is being left behind.
I hope that Safari eventually fixes some of the issues we've seen with delayed or buggy implementations of cutting-edge features. It would be nice to have consistency (although to honest, most of those features are not usable cross-browser in any case, due to Internet Explorer's incompatibility).
Performance, battery life, and UX are generally much better for me than with any other browser, so I really hope it doesn't fall behind too much.
[1] For those to have the fortune to not have been doing web development back then, IE only applied CSS to a small subset of elements, using an internal property known as hasLayout to determine which ones. MS eventually wrote a guide explaining this to web developers: <https://msdn.microsoft.com/en-us/library/Bb250481%28v=VS.85%....
