The Internet Explorer team has announced a meta tag that instructs Explorer 8 to render the page as if it were a previous version of Explorer. The idea is to maintain the exact same rendering, bugs and all, of previous versions of Explorer, so that layouts designed for older renderers never change.

It’s not going to solve the problem

It’s not clear to me that this will work. As the Explorer team and A List Apart would have you believe, many designers who saw their layouts break in Explorer 7 had used a standards-mode DOCTYPE without really understanding what it meant, or didn’t even know that they had used a HTML generation tool that inserted a standards-mode DOCTYPE by default. What’s going to stop the exact same thing from happening with the new rendering-engine meta tag that instructs the browser to render in bleeding-edge mode? Nothing.

It’s not that big of a problem

It’s also not clear to me how big a problem this really is. Sure, if you have a homogeneous corporate intranet where you know every single machine is running Explorer 6, you can design to bugs in that renderer, and then you might need this tag, if you really don’t want to ever rewrite your HTML or upgrade your browsers. But if that’s the use case, Firefox and Safari don’t need it. If you’re designing for the internet, the best strategy is still to design to the standards, and make sure your design works (or degrades gracefully) in as many browsers as possible.

It’s also been my experience that layouts designed to a lowest common denominator of current standards looked fine in Explorer 6, and a little better in Explorer 7. The layouts that broke in Explorer 7 tend to be layouts that were sloppily designed, or never tested in another browser. Yes, designing layouts that worked in Netscape 4 and Explorer 5 and Explorer:mac was hard, and there was a time when Explorer was the only browser worth worrying about. Those days are gone, and it’s just not that hard to design to Firefox 2, Safari 3, and Explorer 6/7 these days.

It’s the same mistake Microsoft always makes

Going a little more meta (no pun intended), this strategy is just a variation on the same mistake Microsoft always makes. The history of the Windows API reads like a campfire story told to scare naughty programmers. Each new version of Windows introduces new APIs while attempting to maintain compatibility with old APIs, even to the point of mimicking buggy behavior. And now Microsoft is making the same mistake with this meta tag in Internet Explorer 8 that it keeps making with Windows.

In Myths, Lies, and Truths about the Linux kernel, Greg Kroah-Hartman argues that maintaining a stable API and ABI across different releases of Windows “acts like an anchor” on development and innovation. The Linux kernel, on the other hand, doesn’t commit to supporting legacy APIs and ABIs. This means that kernel developers are able to make the right design decisions and rewrite broken code without having to worry about continuing to support applications that depend on buggy or poorly designed interfaces.

Apple repeatedly makes essentially the same decision as the Linux developers have. When it switched from Motorola to PowerPC, the Mac OS 7.5 used an emulator to run binaries compiled for Motorola, and new applications were compiled for PowerPC. When Apple released OS X, it provided the Classic emulator so that legacy applications could still run, but new applications had to be written for OS X, not Classic. When Apple switched architectures again, from PowerPC to Intel, it provided Rosetta so that PowerPC binaries would still run. And each new release of OS X comes with application building tools that will build an application for that version of OS X, but no promises are made as to whether it will run on newer versions of the OS. This strategy has the same effect on Apple’s development process as it does on the Linux kernel’s development: the right design decisions get made and backwards compatibility does not act like an anchor on innovation.

In this light, Microsoft’s strategy of continuing to support programs written for DOS, Windows 3.1, and Windows 95 in Windows XP seems, well, questionable. And as each new release of Windows has cool features pulled before release, I can’t help wondering if this strategy has a significant detrimental effect on the product.

Back to Internet Explorer. The Explorer team apparently experienced a backlash from web designers who expected Explorer 7 to render pages exactly the same as IE 6 did, even in “standards mode” and even to the point of mimicking Explorer 6 layout bugs. Sounds like life sucks for them. They are faced with two poor choices: either breaking (some) existing layouts in order to lay out future pages in a more standards-compliant way, or fragment web designs (and designers) into standards-mode and Explorer bug-compatible camps by maintaining bug-compatible layout. This is exactly the dilemma they have faced with Windows, and they have chosen exactly the same strategy to fix it: bug-compatibility.

To be fair to Explorer, this strategy is most like Apple’s emulation strategy. Apple, however, has phased out each emulation level over time. You can’t run 68000 binaries for Mac OS 7 inside Classic on an Intel OS X Mac. Who knows if Explorer will phase out the IE 5 compatibility mode in IE 9 or 10, or ever.

This strategy will probably have exactly the same effect on Explorer as it has had on Windows. The browser code will become more complex and harder to maintain, and it will start to act like an anchor on innovation. The WebKit and Gecko guys don’t want to implement similar tags for their renderers, because they fear it would vastly complicate their code (and they’re probably right). In the long term, this “solution” from Microsoft is probably good news for Safari, Firefox, and Opera, because they will be able to improve their browser as new technologies emerge, unfettered by having to make sure that old renderers are compatible with the new renderer.

This is where the parallel with Windows ends, too. Windows has never had a (serious) competitor that implemented the same API. While this solution means that Windows keeps running old Windows apps and improves slower that OS X and Linux, in the browser space there are serious competitors that support the same API and run the same programs. Windows only has to compete against its previous version; Explorer has to compete against other browsers.

Fragmenting web designs into Explorer bug-compatible and standards-mode camps might lock some corporate intranet users into Explorer, and that’s probably what Microsoft really likes about this proposal. But it’s a double-edged sword; if they have to maintain several renderers and compete against sleeker browsers, as web designers flock to the far superior HTML 5 and away from designs that rely on Explorer layout bugs, it starts to seem like a less appealing strategy.

The best thing for Explorer to do is to keep tracking the current standards and keep fixing bugs in their renderer. And slowly phase out quirks mode. If they really want to keep all previous rendering engines around, they’ve got their work cut out for them, and it’s not clear it’ll do anything but help their competitors in the long run.

Update 2008-01-26: The best part about X-UA-Lemur-Compatible is that one of the the A List Apart lemurs has a beanie on.