Why Safari Is NOT the New Internet Explorer: A Developer's Historical Comparison

Mar 12, 2026

Problem

When I mention Safari bugs to other developers, I often hear: “Safari is the new Internet Explorer.”

This comparison sounds reasonable at first. Safari has compatibility issues. Safari is slow to adopt new features. Safari causes headaches for web developers.

But here’s the problem: this comparison trivializes what we actually went through with IE6. The “Safari is the new IE” label misleads teams about the actual effort required for Safari support.

What the IE6 Era Was Really Like

I worked through the IE6 era. Let me show you what “browser hell” actually meant.

IE6 Had Broken Implementations

IE6 didn’t just lack features—it implemented things incorrectly. Here are real examples I dealt with:

/* IE6 doubled margins on floated elements */
.box {
  float: left;
  margin-left: 10px;  /* Became 20px in IE6 */
  _margin-left: 5px;  /* IE6-specific hack to fix it */
}

/* PNG transparency didn't work */
.transparent {
  filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(
    src='image.png',
    sizingMethod='scale'
  );
}

/* overflow:auto ignored without position:relative */
.scroll-container {
  overflow: auto;
  position: relative;  /* Required or overflow didn't work */
}

These weren’t missing features. These were broken implementations that required magic hacks.

IE6 Had No Feature Detection

The worst part? I couldn’t detect if IE6 supported something. Feature detection as we know it didn’t exist in a meaningful way.

// This works today for Safari
if (CSS.supports('backdrop-filter', 'blur(10px)')) {
  // Safari supports it, use the feature
}

// In IE6 era, we used browser sniffing
var isIE6 = navigator.userAgent.indexOf('MSIE 6.0') !== -1;
// Unreliable and hacky

IE6 Had a Wrong Box Model

IE6 used a different box model by default. A 200px wide box with 20px padding was 200px total in IE6, but 240px in standard browsers.

/* Standard: width = content only */
.box {
  width: 200px;
  padding: 20px;  /* Total width: 240px */
}

/* IE6: width = content + padding + border */
/* Total width: 200px (padding included) */

This broke layouts constantly. I had to use conditional comments and CSS hacks just to make consistent layouts.

What Safari’s Issues Actually Are

Safari has problems, but they’re fundamentally different from IE6’s.

Safari Follows Standards

Safari implements standards correctly. When Safari lacks a feature, it simply doesn’t support it—it doesn’t implement it wrong.

IE6:  Implements feature incorrectly → Layout breaks mysteriously
Safari: Doesn't implement feature → Feature doesn't work (detectable)

Feature Detection Works

I can detect Safari’s missing features reliably:

// Check for service worker support
if ('serviceWorker' in navigator) {
  // PWA features available
}

// Check for backdrop-filter
if (CSS.supports('backdrop-filter', 'blur(10px)')) {
  // Use backdrop-filter
}

// Check for WebRTC
if (window.RTCPeerConnection) {
  // WebRTC available
}

This means I can build progressive enhancement strategies. With IE6, I had no such option.

Safari Gets Regular Updates

IE6 went years between updates. Microsoft stopped developing IE after “winning” the browser wars in 2001. Safari gets regular updates through iOS and macOS releases.

IE6:     2001 release → 2006 IE7 (5 years gap)
Safari:  Regular updates tied to iOS/macOS releases

The Real Comparison

Let me show you a direct comparison:

Aspect	IE6 Era	Safari Today
Implementation	Broken, non-standard	Standard-compliant
Detection	Impossible	Easy with feature detection
Workarounds	Magic hacks, conditional comments	Polyfills, graceful degradation
Updates	Years between versions	Regular updates
Standards	Actively ignored	Followed, sometimes slowly
Box Model	Wrong by default	Correct by default

Why This Distinction Matters

When I say “Safari is the new IE,” I’m conflating two very different problems:

Missing features - Safari doesn’t support something yet
Broken implementations - IE6 implemented things incorrectly

These require different strategies:

Missing feature → Feature detect → Polyfill or fallback
Broken implementation → Debug → Find hack → Pray it works

For Safari, I can plan. I can detect. I can progressively enhance. For IE6, I was in crisis mode constantly.

The Real “New IE”: Chrome

If any browser deserves the “new IE” label, it’s Chrome. Here’s why:

Chrome dominates browser market share (~65% globally). More importantly, Chromium engine powers ~79% of browsers when you include Edge, Brave, Opera, and others.

Chromium:  ~79% (Chrome, Edge, Brave, Opera, Vivaldi)
WebKit:    ~18% (Safari)
Gecko:     ~3% (Firefox)

Google pushes features before standardization, effectively making Chrome the de facto standard. This is different from IE6’s approach but achieves similar dominance.

Summary

In this post, I explained why the “Safari is the new IE” comparison is wrong. The key point is that IE6’s problems were broken implementations requiring specialized hacks, while Safari’s issues are missing features that I can detect and polyfill.

When I hear someone say “Safari is the new IE,” it usually tells me more about their age and experience than about actual browser equivalence. Those who lived through the IE6 era know: Safari’s challenges are inconvenience, not catastrophe.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!