By this time next year, if IE 6’s usage pattern continues to match that of IE5, IE6 will be around 13% – iedeathmarch.org

In my opinion a 13% market share is still too high to drop IE6 support completely for anything intended for consumption by the general public. Let’s not forget that the majority of computer users do not know or care what a “browser” is. They just “click on the e” or “go onto the AOL internet”.

For closed system like admin interfaces or internal web apps I see no reason why system requirements which exclude ancient browsers cannot be enforced. That’s the distinction between a website and a web app. A web app is software, and software comes with system requirements. Obviously the decision to drop IE6 support depends heavily on your target audience. So the general rule of thumb should surely be if your site/app would not suffer from IE6 compatibility don’t bust your nuts making it IE6 compatible.

My preferred method is simple. If I’ve decided that an application I’m developing is not going to be ie6 compatible i will add in some simple browser detection either server-side or with a bit a JavaScript which disables the application and shows a friendly message informing the user that they are using a very old browser. I generally give them some upgrade options in the from of links to the Firefox and IE7 download pages.

If your site or application actually works okay in IE6 but has some quirks that you’re unable/unwilling to iron out another good approach, and one taken by Facebook is to display a friendly unobtrusive message to IE6 users again explaining that they’re using very old software and some parts of the site might look/behave oddly. It would be interesting to see figures on how many upgrades have occurred as a direct result of IE6 users of Facebook. I imagine it’s considerable.

All in the the trends look promising, but no sooner will we forget about IE6 like we did IE5 then we’ll start begging for IE7 and all it’s idiosyncrasies to bow out in the same way.

This one had me stumped. The control panel for our CMS worked fine, just as it had been since, well since forever. The problem was that when visited with Internet Explorer users were now being presented with a brief flash of the login page followed by a 404 Not Found error.

After repeatedly pummeling my desk with my head I noticed that turning off Internet Explorer’s friendly HTTP errors allowed the control panel to be viewed as expected. So why was Internet Explorer in particular interpreting the server’s response as a 404 when it was clearly a 200? I already knew that the server wasn’t issuing a 404 response and the Live HTTP headers Firefox plugin confirmed this.

The HTTP headers displayed by ieHTTPHeaders (Thanks for the tip Lyallzord) told a different story though.

The problem was eventually traced to an incorrectly referenced pngfix behaviour pngbehaviour.htc in one of the control panel stylesheets. To be honest it was news to me that it even existed, but the path was incorrect following a restructuring of site assets hence the broken reference.

It seems that Internet Explorer on recieving a 404 response for referenced behaviour will helpfully 404 the entire document.

So that’s nice.