Actually, IE Was Kind of Right: The Unpopular History of Internet Explorer's Genuinely Good Ideas

Writing this article has required a level of intellectual courage that we frankly weren't sure this publication possessed. We've spent years — this entire website, essentially — processing the collective trauma that Internet Explorer inflicted on a generation of web developers. We've catalogued the CSS disasters. We've mourned the lost weekends. We've nodded solemnly at the * { zoom: 1; } hacks and the conditional comments and the box model that operated according to rules seemingly invented by a particularly spiteful mathematician.

And yet.

And yet.

History, it turns out, is more complicated than the browser wars made it feel. Because when you look closely — really closely, with the benefit of two decades of hindsight and a generous pour of whatever gets you through a retrospective — Internet Explorer was occasionally, infuriatingly, right.

The XMLHttpRequest Situation

Let's start with the most embarrassing one for IE's critics: XMLHttpRequest.

XHR — the technology that made AJAX possible, that enabled the entire paradigm of dynamic web applications, that is the direct ancestor of the fetch API powering virtually every modern web app — was invented by Microsoft. It shipped in IE5 in 1999 as an ActiveX component. The rest of the browser world didn't implement it for years. Firefox, Opera, and Safari eventually followed, and when they did, they were following Microsoft's lead.

The technology that enabled Gmail, Google Maps, and the entire modern web as we understand it was an Internet Explorer innovation. You're welcome to sit with that for a moment.

When the W3C finally standardized XMLHttpRequest in 2006, they were essentially ratifying something Microsoft had shipped seven years earlier. This is not a footnote. This is a foundational piece of web history that gets systematically underemphasized because it's inconvenient for the narrative of IE as pure antagonist.

CSS Expressions: Wrong Implementation, Right Problem

Okay, now for one that's more nuanced. CSS Expressions — IE's proprietary feature that allowed JavaScript to be embedded directly in CSS values — were genuinely terrible. They were a performance nightmare, a security concern, and an architectural abomination that violated every principle of separation of concerns.

But here's the thing: the problem they were trying to solve was completely legitimate.

CSS in the late 1990s and early 2000s had no way to express dynamic, calculated, or responsive values. There was no calc(). There were no CSS variables. There was no way to say "this element should be 100% of the viewport height minus 60 pixels" without resorting to JavaScript. CSS Expressions were a catastrophically bad solution to a genuinely real problem.

Fast forward to 2024 and CSS is full of dynamic, calculated values. calc(), clamp(), min(), max(), CSS custom properties, container queries — modern CSS is essentially the version of CSS that IE was trying to improvise with expressions, built properly. The problem IE identified was real. The solution was not. But identifying the problem correctly is not nothing.

The Vendor Prefix Controversy, Revisited

Developers of a certain vintage still twitch at the memory of -ms- prefixes. The vendor prefix system — where each browser implemented experimental CSS features under browser-specific prefixes before standardization — is broadly remembered as a chaos-generating mistake.

But the original intention was sound. Vendor prefixes were supposed to allow browsers to ship experimental features for developer testing without committing to a specific API before the standards process concluded. The idea was that the -webkit-, -moz-, and -ms- versions would be temporary scaffolding, removed once the standard was finalized.

The problem wasn't the concept. The problem was that developers started using vendor-prefixed properties in production code, often only including the -webkit- version, creating the exact fragmentation the system was designed to prevent. The browsers then couldn't remove their prefixed implementations without breaking half the web.

Microsoft's -ms- prefixes were part of a system that, in theory, should have worked. The industry's collective failure to use that system responsibly is not entirely Microsoft's fault. Not entirely.

IE's Rendering Priorities Weren't Always Wrong

Here's a genuinely contrarian position: IE's notorious tendency to prioritize backward compatibility over standards compliance was sometimes the correct call.

The web is, above all else, a document of record. Links don't break. Old pages stay accessible. This is a feature, not a bug, and it's one of the web's most important properties. IE's aggressive backward compatibility — the quirks mode, the compatibility view, the layers upon layers of legacy behavior — was an attempt to honor that principle, even if the implementation created developer hell.

Chrome's approach of aggressively deprecating and removing features has created its own category of breakage. Sites that worked fine for years suddenly don't, because a rendering behavior changed in a point release. IE would never have done this to you. IE would have maintained that broken behavior for fifteen years out of sheer, stubborn loyalty to the past.

Is that admirable? Probably not. Is it occasionally the right call for a platform that serves billions of people with billions of old bookmarks? The argument is more interesting than most developers want to admit.

What History Actually Owes IE

None of this is to say that Internet Explorer was good. It wasn't, mostly. The box model was wrong. The CSS support was inconsistent. The JavaScript engine was slow. The security record was catastrophic. The market dominance it leveraged to stall web standards development for the better part of a decade caused genuine, lasting harm to the web platform.

But the narrative of IE as pure villain — as an engine of chaos with no redeeming technical qualities — is also wrong. It's the kind of clean, satisfying story that history rarely actually produces.

XMLHttpRequest changed the web. The dynamic value problem was real. The backward compatibility instinct, however clumsily executed, pointed at something true about the web's nature. These ideas deserved better implementations. Some of them eventually got them, from other browsers, under different names, after the industry spent years pretending it had invented them from scratch.

So here, at Internet Explorer Tan — still loading since 1995 — we're prepared to say it plainly: IE was right about some things. The browser that made us all miserable was also, occasionally, pointing in the right direction.

We're going to need a minute.