Safari vs Internet Explorer :: Round 2


We are attempting to determine whether making a one-to-one comparison between Apple Safari and Internet Explorer is a fair one. That is, can we rightly use the phrase “Safari is the new IE”? Note that the parameters we’re examining are primarily related to UI/UX and Front End Development--those disciplines where special conditions to support one browser or another have either been a bane or a source of consistent employment (or both).

In part one, I scratched at the historical context of IE6 and Safari in an attempt to find similarities. And, indeed, there were some. But not, in my opinion, enough to dump Safari in the same browser heap as the IEs (6, 7, 8). We need to do some more digging, starting with each browser’s support for some of the more common and widely used features. Remember, this is not a comprehensive list. If you have more examples, I’d love to read about them in the comments.


When it comes to supporting features, IE and Safari can be frustratingly similar. How many times have you worked through a solution or a new layout, knowing that you would eventually have to add some special IE support, only to hear later “You know that doesn’t work in Safari, either, right?” It doesn’t work in . . . wait, what?! Yup. Safari can be like an 8-year-old off his ADHD meds with how it sporadically and inexplicably provides support.

Screen Shot 2014-08-04 at 10.01.59 AMFor example, neither IE nor Safari support the WebM video format. And while this may not interfere with every developer’s daily tasks, it’s a particular pain point here at Craftsy where video is one of our primary concerns. We serve up a lot of video; it’s kind of a big deal. You know all those CSS gradient fallbacks and prefixes? Well, we need to do a similar type of workaround with video.

Further irritation crops up where Safari gives us a little, but not all, support. Where IE provides no support prior to v9 or v10 for features such as CSS3 background images, pure HTML form validation, and session history management, Safari teases us with spotty and unreliable support. I can’t decide which is worse.

Throughout our CSS and LESS files, we make a special case for Safari to allow pixel dimensions because percentage margins break. We hold Safari’s hand when it comes to vertical alignment. And we generally just feed the browser’s ego when it comes to doing anything regarding “calc” in iOS. For these reasons--and also because we hear daily from our QA team that “there’s a problem in Safari”--I agree that comparing Safari to IE is not only very fair, but also inescapable.


Before you throw all your chips behind Safari in the debugging debate, remember that when the IE Developer Toolbar came out for IE8, it actually did quite a lot. While it wasn’t nearly as user-friendly as Firebug, it did give us developers a chance to finally see what the sh*t was going on with that pesky box model. It had JS profiling, JS debugging, and a console output to view errors (and logs etc.).  Even though it didn’t come pre-installed, it was better than what came before it--which was nothing.

Safari’s Web Inspector, on the other hand, did come pre-installed. You simply had to activate it. . . through the command line . . . and then reboot. It was also missing a few features that the Developer Toolbar for IE included, such as the JS profiler and breakpoints. Where Safari did accel was with its interface: the Web Inspector was well-organized, simple, and much more intuitive than the toolbar for Internet Explorer.

Today’s Web Inspector for Safari and Developer Toolbar for IE have both received significant facelifts and feature enhancements. Both have robust debugging features like breakpoints for JS, DOM exploration, and console tools. So to determine which is “better”, it really comes down to personal preference. On this, I’m going to call Safari and IE a draw.


A speed and performance comparison between IE and Safari used to be one-sided, with Safari consistently out performing IE by a large margin. Earlier versions of Safari certainly crashed less than IE, although one wonders whether that is primarily because of the operating systems the browsers were running on rather than the browsers themselves.

Screen Shot 2014-08-04 at 10.08.46 AM

However, more recent versions of IE have started to narrow the gap between the browsers when it comes to boot-up speed and performance overall. Safari is still ahead when it comes to memory usage and HTML5 compliance, but IE 10, at least, is out-performing its rivals on boot time and speed. In fact, consecutive releases of Safari have actually gotten slower in relation to the other browsers.

One more comparison I’ll lump in here regards speed of browser updates and upgrades. Chrome and Firefox release frequent updates and have the flexibility to solve problems at a faster pace. This invariably leaves Safari languishing with IE when it comes to release versions. Is it enough to say that Safari is the new IE? I’m going with yes on this one.


To get a fair assessment of whether we can say “Safari is the new IE”, let’s look back over our points of comparison:

  • Historical context: No

  • Feature Support: Yes

  • Debugging: Draw

  • Speed and Performance: Yes

There are many, many other factors one could use to compare and contrast these two, very different browsers. This, at least, gives us a benchmark for our Safari-bashing. And while we may come across as trolls when the subject comes up, we will at least be better-informed trolls.

Comments (0)

The comments to this entry are closed.