We all hate coding for IE6.  To be fair, there are those among us who enjoy charging extra for it, but I think we can all agree that it would be nice if IE6 just went away.

Unfortunately, that’s not likely to happen.  With the flop that was Windows Vista, and slow adoption of Windows 7, IE6 is here to stay in the home market for quite some time.  Compounding that are the IT departments that refuse to allow employees to upgrade, due to internal web solutions that were coded (short-sightedly) specifically to work on IE6 and only IE6.

In any case, it’s impossible to know the exact market share of any browser.  The statistics are out there, and you’ll probably see colleagues cite them, but really, they only show the part of the web that was measured.  For example, Net Applications has reported that IE6 has a 22% market share as of August 2010, while website Ars Technica claims it accounts for less that 10% of their visitors.

So how do we deal with IE6?  Code to standards, then ‘fix’ for IE6?  Ignore it completely?

Personally, my approach in the past was to code to standards, and then create a separate IE6 stylesheet which I would use to fix a wide range of bugs, both large and small.  There are those who disagree with this approach, thinking that if we ignore IE6 it will go away.  Actually, the idea is more akin to thinking “If most websites don’t work in IE6, then it’s users will have to upgrade”.  While normally this would be true with technology, you’ll find few companies eager to alienate a sizeable portion of their users, and so they insist that IE6 must work.

My current approach is that of graceful degradation.  I code my HTML and CSS to standards, and I test in Firefox, Chrome, Safari, Opera, and Internet Explorer 8.  Once the code renders well in those browsers, I take a look at IE6, and to a lesser extent, IE7.  I then begin to tweak the code in subtle ways, to make it more palatable for IE6 users.  The goal here is not pixel-perfect accuracy, but rather, a simplified version of the final site.

A few months ago, frustrated with a client site that wouldn’t render properly in IE6, I angrily tweeted that “If IE6 users cared about rounded corners, Microsoft would have implemented them!“  This is wrong for a number of reasons, but the main one is that the average user simply does not know that IE6 is full of bugs.  Frankly, they are using IE6 because that is the browser that came pre-installed on their computer.  They don’t know that other browsers are out there, and even if they do, they are comfortable with this one.

What isn’t wrong with my angry statement, however, is the idea that rounded corners are unnecessary.  Rounded corners are usually superfluous in web design, no matter how badly the client thinks they’re necessary.  They occasionally look nice, but usually look awful, and certainly we have moved past the point where they are considered trendy.  Incredibly rarely do they *make* a design (though occasionally they break it).  If I can render them entirely in CSS, without making scores of different corner images for each different coloured box, then that is best practice.  That way, they will render rounded in most browsers, while IE6 will show them with square corners.

This is a good thing, for you, for your clients, and for the web in general.  You get saved the frustration of coding specifically for IE6.  Your clients save time and money, not having you code for IE6.  Finally, the web as a whole benefits, because most users aren’t using the latest version of Firefox and then switching to IE6 just for kicks.  People overwhelmingly prefer one browser.  As a web designer, I am forced to use no less than than seven (SEVEN!) different browsers on a daily basis, but when I’m surfing on my own time, it’s Firefox all the way.  That’s my personal choice, just as those users who stick with IE6 have made theirs.  But when they do upgrade, or see the same site on a friend or co-worker’s machine, they will see what they have been missing.  This is how the web benefits.  They will be encouraged to upgrade, and possibly encourage others.  The faster the rate of adoption of new technology, the sooner we as designers can reliably implement it, and the sooner everyone reaps the benefits of that technology.

One last thing to note: I don’t advocate refusing to code specifically to IE6.  In fact, I still do it when requested by the client (and yes, I do bill them for the extra time required).  I do however, explain to them the difficulties with IE6 at the start of the project, and possibilities for graceful degradation that won’t affect the overall usability of the website.  The reason I am able to do this is because I know IE6 in and out, and that knowledge is invaluable.