Six of One, A Half Dozen of the Other

Filed under: Development, Design, Web Standards

Tagged: html, doctype, ie6, standards

Molly Holzschlag's talk tonight has given me some much-needed inspiration for my (now late) weekly blog post. Some of the things that she had to say about Internet Explorer 6 have prompted me to cogitate on the way that we treat this dinosaur of a browser at my company.

Anyone who has been working in the Web industry for more than five minutes can probably tell you that IE6 is responsible for the some of the least enjoyable parts of their job. Front-end developers are often required to spend almost as much time fixing Box Model and JavaScript problems in IE6 as they are to write the code in the first place. In my opinion this is simply unacceptable, especially considering that IE6 is over eight years old and has been succeeded by two (soon to be three) newer versions.

Despite this, IE6's market share, while continually dwindling, remains disproportionately high: 17% according to StatCounter's GlobalStats service. While this is less than half of that of Firefox (versions 2.0 - 3.5 combined), this is still an intimidating statistic considering the percentage of users who are not allowed to upgrade or install other browsers due to corporate restrictions.

So how does one provide support for IE6 without breaking the budget of a given project? In my experience the easiest solution to that problem is to not support it at all. Instead, be upfront with your client and let them know that your agency does not include IE6 support by default, and that if they really want or need it they can have it for an extra fee of X dollars (where X is variable, and can be nominal or substantial depending on the scope and complexity of the given project). This approach will tend to work in your favor for a couple of reasons.

First, you will rightfully scare off some of the lower-budget clients who are not as serious about their app as they should be. If they insist on IE6 support but are unwilling to pay the nominal fee, this is most likely an indiction of deeper problems that suggest you are probably better off without taking the job. Second, larger corporate clients will tend to gladly pay the extra fee, themselves realizing that working around the shortcomings of IE6 takes a lot of time. Even if this is not the case, the fee can easily (and fairly, IMHO) be added into existing line items such as usability testing, accessibility, and project management.

All of these sentiments are expressed best in this post by designer and web evangelist Dan Rubin. For what it's worth that post is now a year old. Be sure to read over the article's comments for even more interesting insight from Rubin and others.