Safari is Not the New IE, But…


Developers love to hate on browsers. In recent memory that browser has always been Internet Explorer due to Microsoft’s decision to slow down browser development after IE6. The ensuing developer backlash spawned countless comics, clever desktop backgrounds, and witty conference slides.

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. And increasingly, with the popularity of articles like Nolan Lawson’s “Safari is the new IE”, developers’ new target is becoming Safari. As someone who speaks to a lot of web developers myself (working as a developer advocate for Telerik), I hear this sentiment often. But as a data-minded person, I wanted to see if I could quantify the reasoning behind the animosity.

In this article I’m going to use data from to try to quantitatively determine developers’ most-hated browser. But first I have to discuss what I’ll be measuring, and to do that I have to go back in time a bit.

What makes developers hate a browser?

Internet Explorer has long held the title of most-hated browser, but it hasn’t always been that way. Back in the late 1990s and early 2000s, as Microsoft increased the engineering effort on Internet Explorer, Netscape Navigator’s lagging feature set made it the primary target for developer hatred. It’s hard to find links that still work that illustrate this, but I’ve managed to find a couple gems:

History tells us that web developers have a deep-seated need to rant and make snarky jokes about their most hated browser of the day. The anti-Netscape arguments are surprisingly similar to the anti-IE arguments of the last few years, and the anti-Safari arguments of today.

Although I’m oversimplifying a bit, I would argue that web developers primarily hate two things: not being able to accomplish things they can do in other browsers, and a lack of communication as to why those things have not been implemented. I’ll start with the former (lack of features) and move on to the latter (lack of communication) later. To put this in context, let’s start with an example.

Anyone who has done web development for more than a few years has probably written code like this:

if (document.attachEvent) {
} else {

For those of you that don’t know, IE did not support addEventListener() before IE9. So if you wanted to attach an event listener to a DOM node – probably the most common use case for JavaScript on the web — you had to fork your code and use IE’s non-standard attachEvent() method. Although the workaround was trivial (and often abstracted away by a library), the need to write three extra lines of code for such a simple use case might have done more to incite IE hatred than some of the major features IE lacked for years.

This scenario, one browser lacking a feature, or what I’ll call a “feature outlier”, is one of the major things I believe drives browser animosity, because nearly every developer has a pet feature they’d be able to use if only browser X supported it. For older versions of IE the list of missing features was long, and, if you go back far enough, included major outliers like PNG transparency and a standards-compliant box model.

The IE box model bug was so well known that — I kid you not — it even has its own Wikipedia page.

I personally know of a few feature outliers in today’s Safari. For instance I’ve been talking about how Safari is the only browser without built-in form validation for years now. Nolan Lawson’s “Safari is the New IE” talks extensively about IndexedDB (which Safari has, but it’s unusually buggy in Lawson’s opinion). But, to get a full list of Safari’s feature outliers I had to turn to caniuse.

Measuring feature outliers

One of the great things about caniuse is they graciously make the raw JSON data that drives the site available on GitHub. This data made it relatively easy for me to derive how many features only one browser lacks.

What I did was grab the JSON file, and loop over each feature to determine how many features were only in three of the big four browsers. I limited the test to the big four — Chrome, Edge, Firefox, and Safari — as every other browser (with the exception of Opera Mini) is based on one of the same four rendering engines the desktop browsers use. I also chose to use the latest version caniuse has stats on, which means the data includes development versions of Chrome and Firefox, and Safari 9 rather than 8. You can view my full algorithm here.

Without further ado, here are the results of my feature outlier test:

Browser # of outliers Missing features (no support) Missing features (partial support)
Chrome 1 CSS Hyphenation None
Edge 23 SVG SMIL animation, Server-sent events, Web Notifications, CSS resize property, SPDY protocol, CSS Filter Effects, HTML templates, Canvas blend modes, srcdoc attribute for iframes, Improved kerning pairs & ligatures, Crisp edges/pixelated images, Referrer Policy, CSS3 font-kerning, Form attribute, meter element Drag and Drop, Data URIs, TTF/OTF – TrueType and OpenType font support, matches() DOM method, Number input type, Viewport units: vw, vh, vmin, vmax, Srcset attribute, CSS Appearance
Firefox 5 Media Source Extensions, CSS zoom, Channel messaging WebGL – 3D Canvas graphics, AAC audio file format
Safari 9 Internationalization API, CSS font-feature-settings, User Timing API, Resource Timing, Gamepad API Form validation, CSS3 word-break, Media Queries: resolution feature, Pattern attribute for input fields

Obviously this isn’t the most scientific of tests, but I still find the data interesting when viewed as a rough indication of the features browsers have yet to implement. Edge came out with far more outliers than I was personally expecting, with Safari a distant but significant second.

Why the Safari hating?

So if Edge has more feature outliers, why is Safari receiving so much more hatred lately? I’ll offer two reasons.

The first is communication. Although Edge is missing more features, most of the missing features have a documented status on Additionally, Microsoft has a portal where you can submit and vote on features, and Microsoft has been good about publicizing their stance on larger features, such as their recent articles on web components.

The WebKit project (the rendering engine that drives Safari) has a status page that’s similar to Microsoft’s, however it feels lacking in its completeness. For example prominent web features such as pointer events and service workers are not listed. Frequently, the only place to find where the Safari team stands on an issue is on the W3C/WHATWG mailing lists or the WebKit bug tracker, neither of which are especially accessible to the average developer.

The second reason I’ll offer for the recent Safari animosity is in trends. Whereas just a few years ago Safari was one of the leaders in terms of browser features, it now seems to be quickly losing pace to Edge. To show this I took the data from caniuse and went back a few years. Using the browser version history from Wikipedia, I calculated how many feature outliers each of the major browsers has had over the last five years (again, you can see the algorithm I used and the full dataset here), and put the results in a Kendo UI line chart:

The number of outlier features over the last five years

A quick glance at this chart shows a concerning upward trend for Safari. And since this chart includes data from the not-yet-released Safari 9, and the next Safari release won’t come in the next year, there’s little reason to believe this chart will improve in the near future.

In defense of Safari

All of this is a bit unfortunate, because in my opinion Safari is a really good browser. In my experience, Safari is easily the best browser on OS X in terms of battery and memory usage. (External articles can confirm the battery usage, and I’ll use this comic to justify my memory claims.)

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. Safari’s feature set also isn’t really that bad – it’s on par with Edge on HTML5 Test, and among the leaders in terms of ES6 compatibility.

I titled this article “Safari is Not the New IE” because the thought that Safari is comparable to IE from the IE 7–8 days is ludicrous, except in one way: if Edge’s current rate of implementing features continues, Safari risks dropping into last place on the browser totem pole. And as history has taught us, whether it’s fair or not (usually not), the last-place browser opens itself up to the snarky jokes and memes that the development community loves to create.



  • Sure, they tick off more of the feature list, but it is buggy! Often there is no way of getting around the bug other than doing browser detection and turning off that feature for Safari!

    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.

    • Chris Portscheller

      Indexeddb, poor implementation of position:fixed, and onscroll events being ignored are my biggest complaints with Safari. Also, the fact Apple doesn’t allow third party browsers. There is a chrome browser, but it is in fact just a chrome skin with some extra functionality wrapped around the safari webview.

      • Frank

        “Also, the fact Apple doesn’t allow third party browsers.”

        You’re talking about iOS, then. The rest of the article is talking about OS X. Safari on these platforms is very similar, but not the same, just like “Chrome” on the desktop and “Chrome” on Android are different beasts. Let’s stay on topic.

        • ChrisPollard77

          The article specifically points out, “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.” I believe that is where the comment was aimed. Safari isn’t *A* choice on iOS – it’s the ONLY choice, no matter who releases it.

          • Yea. iOS Safari is absolutely terrible due to their numerous decisions to help conserve computing power. Technically, you can get Chrome on iOS, but it still uses the rendering engine built into iOS, just a different UI.

            It’s completely fair to bring up mobile Safari due to the statement you quoted. I don’t have a ton of experience with Safari on desktop, but it is similar to mobile Safari in that decisions were made that make it different than the other browsers that can cause some odd bugs.

  • Chris Portscheller

    “On mobile I’ll take iOS Safari over any Android-based browser” .. That’s a bold statement as Chrome on Android seems to run laps around Safari. Take a look at and compare the two.

    • Frank

      I went to that page, and selected the most popular current version of iOS (8.0) and the most popular current version of Android (4.4). According to them, the scores are iOS 8 = 405, Android 4.4 = 379.

      That’s actually rather generous towards Android. While iOS 8 is over 80% of iOS users, Android 4.4 is not even 40% of Android users. The second most popular version of Android is 4.2, which scores a measly 228.

      Chrome on Android only beats Safari on iOS if you have the tiny sliver of users who have all upgraded their operating system and browser. Call me crazy, but I want the median user to be able to use the webpage I’m building, and at that, iOS Safari is far ahead of everybody else in the mobile space.

      • AlfonsoML

        You’re comparing “Android”, but you should have checked Chrome for Android (remember, in Android anyone can provide a rendering engine like Mozilla does), and then you’ll see that the score is 518, not 379 and you can install Chrome in any Android 4.1 and up. Even Firefox Mobile scores higher than Safari.

        • Also Android since 4.4 uses Chrome’s webview now. So the low reading is ridiculous.

    • egojab

      Call me crazy, but I prefer to actually use the browser that visibly and noticeably performs better on actual pages instead of just ticking boxes on a feature checklist. Chrome has become a bloated beast on every platform. Safari is the lean browser Chrome used to want to be.

      • When you develop for Safari, then you’d realize it doesn’t follow standards more than what IE used to do. That means extra efforts from developers to support Safari.
        Speed and bloat has nothing to do with development part.

        Anyway choice of browser is personal, but when comes to development and you find one browser incompatible, you really hate it from bottom of your heart.

        • egojab

          I do develop for Safari, and I don’t need to create any workarounds. I’m not developing complex web applications though that require some of these things, such as IndexedDB. It’s not as if Chrome or Firefox are without their own bugs or incompatibilities. Overall, as developers, what makes our lives easier and less frustrating shouldn’t actually be the end goal, it should be to account for the needs of our users.

          As a developer and a user, the whole “only works in Chrome” nonsense is far more frustrating, and for more damaging and IE-like than the simple lack of certain APIs that are relevant to a small number of sites.

          • Have you worked with Flexboxes? For me its the biggest issue with Safari.
            Also I develop cross browser for modern browser and only Safari requires hacks, a lot of it. It’s not Chrome one.

          • egojab

            I haven’t had any flex box issues in Safari for at least a year, and in iOS 9, it’s no longer prefixed either, so that makes it even easier. it could have been unprefixed sooner, but that’s hardly a “hack”.

          • My entire layout is skewed in Safari which works on all other browsers. Thankfully my client don’t care about the Safari so I got away but there’s no way Safari doesn’t have issues when it works in all other browsers including niches like Maxthon.

          • egojab

            Perhaps you should have a second set of eyes to look at it, because for all the problems Safari has, Flexbox implementation isn’t really one of them.

          • Quite possible. I mean its not like other dev, qc team and client are looking the same page.
            Oh wait, they are

          • egojab

            Ok, well get indignant and offended at the helpful suggestion then. No skin off my back. Safari isn’t a perfect browser; it has it’s fair share of bugs and less than great implementations of features. Flexbox just isn’t one of them.

          • Clearly your suggestion is not helpful in any sense. Just saying Safari doesn’t have flexbox issue when it clearly has in my case, clearly tells how ignorant. Also, to be honest, every browser has some issue with Flexboxes, Safari just have issue with basic ones too.

          • egojab

            Ok, so do get offended like a petulant child. Of course, it’s not at all possible you made a mistake in implementation when thousands of developers/designers don’t have any significant flex box problems…you’re just that unique…

  • Duke

    i don’t dislike Safari on desktop, but Safari on mobile is TERRIBLE in terms of standard compliance and expected behaviours, it deserves some serious developer jokes

  • Dominic Watson

    Why is nobody talking about how buggy it is? I’d go as far as to say that transforms basically don’t work in Safari. Have to totally disable them as they’re glitchy as hell. Text flashing… elements disappearing. It just does not support transforms.

  • AlfonsoML

    For me the main reason why I don’t even try to test or care for Safari is just that I would need to buy a Mac to use it, and that’s a real expensive way to test things.
    Firefox and Chrome are cross-platform.
    IE and now MS Edge provides virtual machines to test any version that you would like.

    With Apple the only option is to buy one of their shiny toys.

  • johngf

    The source of “Reasons why Netscape sucks” may be old-skool, with font tags everywhere, but it is at least very tidy, nicely laid out and tiny. Maybe nostalgia ain’t so bad after all.

  • While the number of Microsoft Edge outliers shown in the table is relatively high, it doesn’t really show a correct picture:

    * CanIUse… doesn’t include JavaScript (except a few features). Edge is leading at ES6 support. The picture would be much kinder on Edge with this included
    * SPDY is included. SPDY was supported by IE, but deprecated in Edge in favour of HTTP/2. The latter is a standard and is the one that should be used, not SPDY.
    * SMIL is not something we will implement as it is agreed that this is on the way out. It is best for the Web to have a common animations model, and SMIL is incompatible with CSS animations/transforms. Web Animations is the way forward here
    * Filters is supported but behind a flag. This is the more responsible way of doing things than putting behind a vendor prefix that sites come to rely on and cause interop issues for other browsers.
    * Data URIs are supported. CanIUse gives partial due to an edge case of very large Uris (larger than you should responsibly use)
    * TTF/OTF are to standard. CanIUse gives partial due to the installable flag. We conform to the spec.
    * number input is given partial due to not showing number spinners. UI is not part of the spec (little spinner buttons don’t really make sense on touch where they’re too small to touch)
    * With viewport units it is only the vmax value not supported
    * CSS appearance until very recently (and the versions implemented) was non-standard. Firefox and Webkit support different values. Edge supports the most used one that is shared between Firefox and Webkit browsers: appearance: none (we support with -webkit- prefix, as that is how it is used on the Web)

    Of those left, a bunch are under active development in Edge.

    There are also additional things missing like getUserMedia/MediaCapture which is not in Safari 9. So while I support the conclusion that Safari is not the new IE, the delta between Edge and other browsers is not as big as shown here.

  • Safari is not new IE, its far worse than that. IE either had the feature or not, while Safari has wrong implementation in a lots of cases.

    My webpage with Flex looses entire layout in Safari but works great in every browser and IE9+, even on desktop.

    I’ve officially stopped supporting Safari, and apparently my clients are getting onboard with it now.

    • Alan Spencer

      Indeed, Safari is even worse than IE in HTML5 Test!

      • Bad thing is when started, they’re top in the list.

        • Alan Spencer

          Almost, Safari was 2nd after Chrome, but still very high. And now it’s the last.

  • Dan

    Safari is my only browser I use and like it the best! The others just keep getting bloated, especially Firefox these days! Safari has a simple interface and everything works the way I want like opening a folder of tabs, only tabbing to fields in the webpage, among others. I keep Firefox around for when things act weird in Safari, but that is a rare occurance.

  • Dan

    All of you guys whining….you have El Capitan and iOS 9 and submitting bug reports and asking for Apple to fix these bugs aren’t you? In my experience they usually listen and fix the bugs if you use the proper channels like bug and Feedback Assistant in the OS now.

    • Flexbox issues are long pending despite the reports. They don’t give a shit

  • Some updates: font-feature-settings just dropped in WebKit (the engine behind Safari):
    Backdrop filters also just dropped:
    Oh yeah, will-change is also in the house:

    And WebKit is leading in CSS4 selector implementation: (you can run the test at All of this is from following @WebKit and various WebKit/Safari engineers and volunteers on Twitter. It’s not a secret what Apple is doing…

  • Dan

    What makes me made is Google…..Apple has pretty much set the standard for h.264 and hopefully h.265 soon and pushing HTML5 for years and then you have Google coming in and pushing their webm/vp8 crap that they want standard and it just mess everything up and causes a mess with fragmentation. Not to mention them keeping Flash alive when these plugins need to go away!

  • Why don’t we accept the fact that no browser is perfect!!! They all have theirs ups and flows and since we have accepted to have many browsers with different rendering engines etc, we might as well just simply accept the differences. it’s a pain but you will get over it eventually fellow DEVs.

  • What about if you include accessibility in your calculations?

  • Pingback: News for Designers - Bootstrap 4, GitUpKit, CSS Modules, Material Design()

  • Pingback: Weekly News for Designers (N.299) | News & Video()

  • 80s Rocker

    This is a terrible comparison and the card are stacked against edge. Let’s put Edge against versions of Safari, Firefox and Chrome that are not officially released. If you really want to be far compare the officially released versions of each browser, not development versions.

  • Pingback: Weekly News for Designers (N.299) | Blog Kornukopia()

  • Ilze

    As an IT company Reproto provide a wide range of services for your brand online. We start with website design and development, moving forward to promotion via games, search engine and social media optimization. More information you can find:

  • brianary

    “Pet feature” is pretty condescending. How about “great idea requiring or significantly benefited by a feature”?

  • brookes stephens

    Safari still hasn’t fixed the TextNode.splitText() bug. I had a project recently where being able to do this would save me a good amount of effort, but alas… i can’t use it 🙁 … it even works in IE9…. other than that Safari is very performant

  • (╯°□°)╯︵ɐɔ‾ʞɔǝɥɔ

    You forgot to mention the fact that, if you are not on Mac, you must buy a computer just for testing a web site on Safari..

  • Pingback: webMASTAH.weekly.002 | webMASTAH()

  • aPoCoMiLogin

    Lets look at WebRTC – MS said that they won’t implement it, they have own “better” version of WebRTC, but they still didn’t anything with that. Then edge comes with win10 and they claim that they’ll implement WebRTC into it. Looks like other company than MS sees that.

    Now lets look on safari and apple statement: we have facetime, don’t need any other standards.
    Safari is calling new IE because they threat it like MS did in IE6 days. They don’t give a shit about developers asking them. Same as MS did.

  • Pingback: What Progressive Web Apps Mean for the Web - Telerik Developer Network()

  • Nigel Wade

    For me the comparison of Safari is the new IE is based upon the fact that it has a large market share due to Apple monopolising browser availability on iOS (i.e. users have no choice) but despite that popularity it lags behind terribly in terms of modern features. I don’t think the browser itself is anywhere near as bad as IE, It’s just annoying from a developers perspective that such a large market share by such a large company with such a large monopoly is holding progress back.
    Actually that and the fact that most releases of Safari nowadays seem to feature a large number of system integration features rather than web features, like IE back in the day.