Safari Is Not the New IE, But…(developer.telerik.com)
developer.telerik.com
Safari Is Not the New IE, But…
http://developer.telerik.com/featured/safari-is-not-the-new-ie-but/
58 comments
Wake me up when Chrome or Firefox have decent accessibility and then explain to me why I should care about indexeddb support over battery life or accessibility.
IE only ever had decent accessibility support because it was ubiquitous and third-parties provided a solution.
IE only ever had decent accessibility support because it was ubiquitous and third-parties provided a solution.
You know, I'm getting quite tired of the accessibility argument.
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.
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.
I can't comment on desktop Safari, but mobile Safari certainly deserves the hate it receives.
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.
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.
Mobile Safari also deserves hate because Apple prohibits all alternatives. You cannot ship a browser for iOS unless it uses Safari's engine. There's no technical reason, it's just a decree from Apple about what they'll allow.
There is very much a technical reason that third-party rendering engines won’t work: JavaScript JIT. Basically, for JIT to work, a process has to be able to mark a piece of memory executable, which would cause all sorts of issues with sandboxing/security.
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.
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.
Since UIWebView doesn't do JIT, as you say, and third party browsers using UIWebView are allowed, I don't think this theory holds up. The inability for third-party engines to do JIT certainly is a problem, but it doesn't look like the problem that causes Apple to make this restriction.
If I remember correctly. That wasn't spelled out exactly. I think the policy that browser vendors are referring to is one that says something like "[no app can duplicate functionality that's in the OS]" or something to that effect.
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.
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.
I'm pretty sure Opera for iOS uses it's own renderer:
https://dev.opera.com/blog/opera-mini-8-for-ios/
https://dev.opera.com/blog/opera-mini-8-for-ios/
This is either a loophole due to the fact that rendering happens server-side, or Apple just hasn't bothered to smite them yet. The rules are extremely clear.
The author lost me when he wrote "On mobile I’ll take iOS Safari over any Android-based browser..."
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.
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 absolutely hate mobile Safari. I've got a dozen workarounds for various things in my code and still can't get a few things to work quite right.
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.
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.
A note to the author: the line graph is pretty much indecipherable to people who are red/green colorblind, which for men is about 5% of the population (it's much more rare in women). I'm not sure if there are tools to help with picking colors for Kendo UI, but there are general tools to help pick colorblind-friendly schemes such as http://colorbrewer2.org/
When working on client side js it often feels like safari is the modern browser that the most special care is required for. Some of this has to do with not the most recent version but the one one before that (much like the most recent IE was often not reqao, people cursed IE).
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)
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)
This was true in the past but, I was under the impression that you could run the server version of OS X on non-mac hardware.
At least by http://www.quora.com/How-do-I-run-Mac-OS-X-on-a-non-Apple-co... and http://www.quora.com/Is-it-illegal-to-install-OS-X-on-non-Ap... it is technically possible (though unstable) to run OS X on non-Apple hardware, but illegal. No mention that it is legal to run the server version of OS X on non-mac hardware.
Maybe I should have been clearer. In the past you were not allowed to run OS X server in a virtual machine on non-apple hardware because of licensing restrictions. They loosened this restriction so that you can run OS X server in a virtual machine on non-apple hardware. Those sources are irrelevant to that.
I was responding to "Meanwhile there is no amount of money Apple will accept from you to run a mac vm on non Mac hardware." And this is not true for OS X server.
I was responding to "Meanwhile there is no amount of money Apple will accept from you to run a mac vm on non Mac hardware." And this is not true for OS X server.
As far as I know the only restriction they loosened was the number of VMs you could run on Apple hardware. OS X server hasn't been an actual version of their OS for a while, it's just an app in their store now.
That said, I would be thrilled to be proven wrong about this.
That said, I would be thrilled to be proven wrong about this.
Can you run safari on osx server?
IANAL, but is contract infringement actually illegal? It may not be without consequence, but it is against the law?
IIRC, it's illegal according to civil law but not illegal according to criminal law.
I don't know much about how Safari is for developers, but in my experience it is currently the best browser for the mac. The general performance of the browser (don't know about js benchmarks) and energy usage are a lot better. Also js based drag and drop is remarkably responsive, a lot more so than Chrome and Firefox. It does have a weird thing where it doesn't load Google sites for me sometimes.
Refering to Safari as "the new IE" isn't a comment about whether it's a good browser or not. It's because Safari is lagging some way behind the rest of the browsers when it comes to implementing new features based on standards. The problem is best illustrated by CanIUse.com ... http://caniuse.com/#compare=firefox+40,chrome+44,safari+8 ... Scroll to the bottom and look at the "Mixed support" table. Lots of green in the Chrome and Firefox columns, while there's lots of red in the Safari column.
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.
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.
Safari / Webkit used to be the leader and get all the new features: CSS Animations, transitions etc.
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...
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...
There are a couple of qualms I have with this article:
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.
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.
Mobile Safari does offer the occasional pain, but older Android browser versions are my current headache inducer. I have to test all my webview content changes twice on Android, once for before API 19 and again for after.
Here's another view: https://html5test.com/compare/browser/chrome-44/ie-Edge/ie-1...
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.
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.
Comparing Browsers based on their feature set is a pretty bad idea imo. For example it probably has a reason why Safari doesn't support WebRTC, and it's not that they are too lazy to implement it. Is Safari a bad choice for Mac users only because there are some features missing? Hell No. For casual Mac users it probably is better to not include those features, and it's even better to not have features which are buggy (as in other browsers).
I do agree with this assessment.
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.
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.
This article is slightly wrong in one regard. The special ire for IE was drawn in part from the fact that features were grossly misimplemented. The infamous box model bug is mentioned, but it's curious that the hasLayout bug is not [1]. IE6 was drawing enmity for its bugs long before its lack of HTML5 or CSS3 features; although, to be fair, HTML4 and CSS2 were themselves horribly buggy, unimplementable specifications. Its the similar bugginess of Safari (e.g., IndexedDB) that's causing people to compare it to IE6.
[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%....
[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%....
I think the worst thing about Apple is the lack of transparency. I haven't checked for some time, but if you file a bug that's already been reported they just close it. You don't get to see other people's bugs so you just get to wait. And there's nothing quite as frustrating as finding a WebKit bug, finding out it's already been discovered but the only real information in their tracker is a message for Apple employees about where the buf can be found in the internal Apple bug tracker.
It looks like the author is doing quite a bit of cherrypicking. How many of these features are "nice to have" vs critical? The only critical feature for me is getusermedia, as our application can't work without it. Edge supports it, but Safari doesn't.
Right now for my work, IE11 is the new IE. It has spectacularly bad performance issues in its nooks and crannies that slow our web application down by a factor of something like 1000 (it's hard to tell -- but after two days of hacking away inexplicable hotspots, it's running 10x faster and still glacially slow). (Switching to IE10 compatibility mode makes the performance problems disappear.)
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.
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 suppose that's why IE has been discontinued and Microsoft developed "Edge".
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.
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.
I've not blogged about the issues (I don't understand them well enough yet). Anything to do with calculating and manipulating the dimensions of elements (e.g. divs with fixed sizes) seems to be awful. (I'm getting something like 0.1s per call to jQuery's .offset() and .outerWidth() methods.) And switching to IE10 mode these problems disappear like magic.
IE11 is "Edge".
No, they're actually different browsers, though both came with windows 10.
https://en.wikipedia.org/wiki/Internet_Explorer_11
https://en.wikipedia.org/wiki/Microsoft_Edge
https://en.wikipedia.org/wiki/Internet_Explorer_11
https://en.wikipedia.org/wiki/Microsoft_Edge
Microsoft calls the rendering engine in IE11 "Edge" as well, as can be seen in the developer tools:
http://i.imgur.com/Y7SKKja.png
http://i.imgur.com/Y7SKKja.png
Edge there means that the either HTTP header or META (don't remember which one exactly) won't specify IE version number and instead will use whatever is the latest version of the browser is. In IE10 this will mean IE10's engine, in IE11 this will be IE11's. This convention is several years old and predates Edge the browser.
I don't think "Edge Mode" rendering in IE11 has any relationship to the browser also named Edge. "Edge Mode" was around at least as far back as IE8. It's not the proper name of the engine.
Oh -- I stand corrected. Teaches me to ignore Microsoft for years... (I must say it's confusing the way IE11's settings are worded.)
That makes IE11 even worse since it hasn't abandoned compatibility and still performs incredibly badly. Maybe Microsoft is deliberately sabotaging it to move people towards "Edge".
That makes IE11 even worse since it hasn't abandoned compatibility and still performs incredibly badly. Maybe Microsoft is deliberately sabotaging it to move people towards "Edge".
The problem is that you have all your corporate customers who still insist on using webapps written with ActiveX and webpages that are still accessed by IE6 users. They would be more than a little upset if Microsoft told them "we're not supporting you anymore".
Microsoft is stuck here: they want to move on to modern web standards, but they can't afford to piss off their corporate customers.
Their solution is to split the web browser, shipping Edge for the consumer market (and the modern members of the business market) that wants to interact with the modern web, but still continuing to provide IE11 along with the OS to keep their corporate dinosaur customers happy.
Microsoft is stuck here: they want to move on to modern web standards, but they can't afford to piss off their corporate customers.
Their solution is to split the web browser, shipping Edge for the consumer market (and the modern members of the business market) that wants to interact with the modern web, but still continuing to provide IE11 along with the OS to keep their corporate dinosaur customers happy.
Edge is IE12. They forked the Trident engine to remove all the legacy stuff. Otherwise, everything else is the same and gets the same new stuff that IE12 would have. No different.
No, IE11 is available for Win7 and Win8.
Edge (the version number is 20) is available only for Win10.
Edge (the version number is 20) is available only for Win10.
Edge runs a modified version of the trident engine, which is pretty peppy and drops all the legacy ActiveX stuff. It is absolutely not IE11. It also seems more secure. The recent IE 0-day patch last night doesn't apply to Edge, for example.
I have no idea if it will be successful, but kudos to MS on finally getting off the IE trainwreck. Now if only they'd release it for 7 and 8.
I have no idea if it will be successful, but kudos to MS on finally getting off the IE trainwreck. Now if only they'd release it for 7 and 8.
"But, as Microsoft has substantially ramped up their work on the web platform and Edge, it now feels unfair to make them the butt of the joke."
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.
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.
If I read this correctly, you hold a grudge against IE6 and this makes you disagree with the statement?
"Burdened with IE support".. surely you don't mean IE6 though?
"Burdened with IE support".. surely you don't mean IE6 though?
>On mobile I’ll take iOS Safari over any Android-based browser, as I find iOS Safari to be far more performant for my daily web browsing
Yeah, not like it has a different engine and the others are required to use a lesser one...
Yeah, not like it has a different engine and the others are required to use a lesser one...
I don't see how Apple is sabotaging the performance of Android-based browsers. Please explain.
I don't think it's fair to compare the same browser (by name, at least) on two distinct operating systems. I believe that the sentence in question is biased by the use of any other browser on iOS, comparing thus iOS Safari with other browsers running on the same OS.
I didn't try to start an argument on Apple sabotaging it's competitors...
I didn't try to start an argument on Apple sabotaging it's competitors...
Android browsers do not, by definition, run on iOS.
What I would give for a mobile device offering duel boot between Android and iOS.
I've invested heavily in both in terms of apps and usage over the years, not to mention dev and testing and can't bring myself to stick to one exclusively.
I've invested heavily in both in terms of apps and usage over the years, not to mention dev and testing and can't bring myself to stick to one exclusively.
The point was very clearly "I would rather develop for Safari on iOS that for any browser on Android."
It does't. Your comment is false.
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.