About a month ago, I found myself In a terrible debugging situation. A web app that I had carefully QA’d in both an IE 8 and IE9 environment was receiving a slew of bug requests from users. Some of these we’d expected. The use of several minor CSS3 tweaks meant that the visual experience was intentionally degraded in IE, but many of these we hadn’t.

Script timeout errors popped up randomly throughout the enterprise.
IE 666 users complained and I wasn’t allowed to take appropriate action.
Layout quirks surfaced.

Even more troubling was the discovery of radically different layout interpretations between builds of IE 8. My testing had proved inadequate because minor build number differences were interpreting the css in radically different ways. Since the app had managed to make it into production with these issues, and fully repairing all of them looked to be a slog I didn’t have the temporal luxury of pursuing; I punted. I threw up conditional comments to repair the issues that were preventing casual browsing. Then I hid the login box for IE users; replacing it instead with a Chrome Frame install prompt.

The results were immediate. My complaint volume dropped astoundingly. More importantly, the number of unresolved Scorchers went to zero. At the same time, no one complained about needing to install Chrome Frame. I had a few issues with insufficient permissions, and a few lingering CSS tweaks that needed rolled out, but the ease of the fix really was astounding.

I’ve since retrofitted most of my production apps and web servers to take advantage of my users newly capable Microsoft Browsers and plan on making the strategic retreat a deployment strategy for many new projects. While I don’t plan on abandoning support for IE, I look forward to minimizing its impact on project risk.

Note:  This post was updated on 2011.6.16 due to a mistake in my account.

• Who Uses Ajax Bestiary
• Getting Started With Chrome Frame