blog ie8 and why the ie team still cant code its way out of a wet paper bag

IE8 and why the IE team still can’t code its way out of a wet paper bag

Look, I’m sorry. I’m sure Microsoft’s Internet Explorer team is full of smart, passionate, and talented people. But their latest effort, the Internet Explorer 8 beta, strongly suggests that they have some issues they need to work out—like maybe not having nearly enough competent programmers to write a modern browser, or living in an alternate reality where web standards are somehow completely different.

Let’s back up a few months. We’re in December, four days to Christmas, and the IE team triumphantly announces that early builds of Internet Explorer 8 successfully pass the Acid 2 test—a stringent test of browser standards compliance that even current Firefox releases have trouble with. Many web developers (including myself) subsequently cheer as Microsoft reveals that standards compliance will be a major new feature in the upcoming browser. Finally! After the complete abomination that is IE6 and the partial abomination that is IE7, Microsoft is taking a hint from Firefox, Opera, and Safari and working to make web developers’ jobs easier instead of harder. Hallelujah!

In light of the IE team’s promises, it was with great excitement that I installed the IE8 beta last night. Finally, an Internet Explorer browser that would flawlessly render everything on the Web without requiring ugly workarounds and lines upon lines of browser-specific code. It was with equally great disappointment that, after rebooting and loading up TR’s front page, I noticed that IE8’s "standards mode" rendering engine butchered TR, misinterpreting simple elements and apparently refusing to let me click anything on the navigation bar at the top of every page. Could it be that IE8’s standards compliance was so great that it had highlighted problems with my code that other browsers didn’t? After a quick look around other sites, I was quickly reassured: no, the "standards compliant" engine in the IE8 beta is just an abject failure.

You see, the IE8 beta has problems rendering a lot of pages. And I mean a lot. Rendering problems occur anywhere from Microsoft’s own Internet Explorer subsite to the World Wide Web Consortium’s validation page. Yes, IE8 fails to properly render code made by the W3C, the very body that defines web standards, on the very page web designers use to validate their code. Don’t believe me? Check out the image gallery below for a quick peek at IE8’s freak show of rendering inadequacies. The only thing the browser did seem to render properly was the Acid 2 test—I suppose Microsoft did at least deliver on one of its initial promises there.

Here’s a protip, Microsoft: if your browser’s new, purportedly standards-compliant rendering engine fails to properly render a large number of major sites, including the damn W3C validator page, you’re doing something wrong. Now, I’m sure these rendering problems could just be the result of bugs inherent in a beta release. Maybe the final 8.0 release will render everything just fine. Maybe I’m just getting worked up over nothing. That would make sense, wouldn’t it?

Then again, according to one of the latest reports we’ve seen about IE8, the full production release will come out before the middle of the year. That means Microsoft has about three months to iron out all those bugs and transition its browser from "more broken than early, alpha-quality Firefox 3 nightly releases" to "not broken and fully standards compliant." Yeah, that’s gonna happen. Here’s what I expect: some bugs will be fixed, compatibility will be improved somewhat, but IE8 will still introduce behavior inconsistent with every other browser on the planet and I’ll have to change TR’s code to make it compatible. Either that or I’ll have to add a header to make it fall back to IE7 compatibility mode when it renders TR.

Have another protip, Microsoft, you deserve it: a web browser’s job is to do its very best to render code in a way consistent with what the web designer expected, not to force said designer to rewrite his code to work with your browser. A small Norwegian company with what must be a staggeringly small fraction of your resources has been able to do this for years.  Why can’t you?