Increasingly I’m reading of web developers deciding to drop IE6 from their list of supported browsers, usually, because of its creative interpretation of CSS standards, besides IE7 is over a year old, and, IE8 about to be released.
I’ve decided to continue support for IE6 as it’s still in wide use – especially in corporate environments – and, I don’t think it needs to take a lot of work to develop for. I’ll say that again, I don’t think IE6 is as bad it’s sometimes made out to be.
IE6 is the difficult child of the browser family – but like most difficult children, with the right tools it can be made to behave. IE7 is better behaved than IE6, but let’s not fool ourselves, it’s not the glowing example of a perfect browser, and requires hacks of its own.
Standards Mode
The best tool to reduce IE6‘s development time is to move the browser out of quirks mode and into standards mode using an appropriate DOCTYPE, and, leaving off the XML declaration; I code in XHTML Strict, so my files begin:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">In standards mode the browser will inherit font styles within tables, use the W3C box model and vertical alignment defaults.
Comments
Create a standard comment format for your main CSS file which you can use when you know you’re going to have to write a hack for the IE6 style sheet, such as /*HACK ie6 ... */; rather than flicking between your main and IE6 style sheets during standards development, you can just search for hack comments during non-standards development.
#someDiv {
min-height: 300px; /* HACK ie6 - height: 300px */
float: left; /* HACK ie6 - 3px jog (adjacent), zoom: 1 */
}Surprises
Once you’ve specified the DOCTYPE, and, repaired known hacks, IE6 is likely to surprise you with a few more creative problems, positioning, an extra few pixels here and there and other little tricks; but by ruling out the obvious in advanced, overall debugging will become less time consuming.
As I said above, IE7 requires its own set of hacks. If browser specific debugging is required anyway, I don’t think it’s overly time consuming to continue support for IE6.
Comments
7 responses to “Why I will not be dropping support for IE6”
Recently I’ve thought about charging extra for IE6 development. So still supporting it but not being part of core business. That is, not supporting it by default, only by request.
I suppose the other side is to just include extra time in your quotes but it’s better, I think, if we start clients thinking that maybe it’s costing them money to still be using IE6. After all, it is largely businesses with locked down SOEs that are the major culprits. Even my parents upgraded to IE7.
I agree. I find that in XHTML strict *most* of the crazy ie6 things are predictable in advance. I just code in all the -3px hacks as I go and don’t have a lot of problems.
I’d be interested to see recent statistics for who is still using ie6. I know that a lot of my clients only have ie6 installed, and can’t get permission to install anything else. Amongst general users I’d guess the percentage would be much smaller? But that’s just a guess. Even my grandparents use firefox :D
I think you are 3 years back :)
lol. Some of my clients still beg for IE6. What I do is, charge them for IE6 styling additional .
I think that this article fails to see the main problem with IE which is that is not a standard complaint browser and that by any means you need to spend extra time and effort to make Website work with it specially as the Web moves forward and clients start asking for specific functionality.
As a developer I have already placed numerous tools to deal with almost every little bug and crazy thing that IE6 has thrown my way. This has resulted in a lot of time, money and effort put into making this browser behave the way it is expected to behave according to the guidelines put forward and, we can say approved, by the Web Development community. Even so, I still run, on a daily basis, into unexpected behaviors specially when I am creating new scripts to improve on my interfaces or to accomplish something in a better way.
By keeping support of IE6 at no extra charge or at no consequence for Microsoft, IE6 will still be a nightmare for us Web Developers and I think that 10 years of a bad browser is enough, specially when there are so many better alternatives to it. I think it is our duty as Web people to educate the masses, our clients into understanding that the IE icon is not the internet and merely a program used to surf the Web and as so, it can be changed for another better piece of software.
I’ve almost fully dropped support for IE6 at least actively testing for errors/bugs in IE6. Very little traffic at this point is IE6 and it saves me that much time, especially on the JavaScript side since we are not currently using a framework.
Interesting comments. I still make sure websites are viewable in Ie6 and look decent. It really depends on the audience of what the website is for. If it’s for web saavy college students at tech schools, I think you don’t even have to think about it. But charging extra for IE6 development? That is VERY interesting, I will keep that in mind next time I end up taking another freelance job.
I’ve enjoyed seeing the path these comments have taken, part of the reason for writing this article was as an agent provocateur to induce discussion, but – to be clear – the intention to support IE6 is sincere.
The talk of charging more for IE6 development has surprised me; I’m not dismissing it out of hand, but I look at in the other direction.
Presumably customers have been paying for IE6 development – unless your giving time away free – I view it as quoting a lower base price and listing the additional work for IE6 as an optional component.
Removing a charge for something the client doesn’t want can’t be dismissed; it suggests the best way forward is a better understanding of a client’s needs and their visitor statistics.