In defense of IE6
August 10th, 2009
No really! Read that title again. I’m about to argue against placing so much blame for painful Web development at the door of Internet Explorer 6. I’m not going try and claim that IE6 isn’t a huge pain in the arse of all good Web developers. Let’s face it, Web developers love to bitch about it, but I do think that it’s time for some accountability.
The problem with IE6 is simple. It has poor support for Web standards. It doesn’t always correctly render valid HTML and CSS, and requires nudging, tweaking and finagling in order to display the content in the desired way. Its interpretation of Javascript and interactions with the DOM are also less than perfect. That’s a pain, but does it really warrant such massive hatred from Web developers? As a Web developer, my first instinct would be to answer, ‘well, yes’. The cost of developing for IE6 is extraordinarily high, even when compared to the benefit from its market share, because it is such a horrible and time consuming slog.
But hang on a moment. The Web is something of a meritocracy. People tend to vote with their feet (or mice) and will abandon the weak experience in favor of the strong. Doesn’t this concept stretch to the browser too? Surely if IE6 was really that bad, people would have abandoned it and adopted a better, newer, more well behaved Web browser. Right? Yes and no. Many people have done exactly that. They have upgraded to IE7, IE8, Firefox, Safari, Opera, Chrome or something else. Let’s be honest, it isn’t hard to find a better browser than IE6 these days. But it isn’t quite that simple.
First of all, not everyone who uses the Web really understands what A Web browser is. Many people just know that they click an icon to get to “The Internet” (by which they often mean Google) or directly to their email (by which they mean one of the many Web based email services). Understanding that they could choose a different application which accesses hese services to perform these tasks is something of a cognitive leap.
Others realised that they could use a better browser and have upgraded the browser on their home computers, but at work they are locked in to using whatever the company IT department dictates. Often, this means IE6. Why is that?
This is my beef. It’s not that IE6 is out-dated and substandard (although it is), but that large organisations have needed to lock users in to using an approved Web browser. Having worked in a few large organisations, I’m no stranger to that scenario, and it’s immensely frustrating to be a user forced to use something so sub-par, and to be required to support it when you are trying to build the Webs next new hotness. So why do they do that? There can be many reasons, but the largest, and most difficult to dispute is actually of our own creation. We (the Web developers of the world) built expensive, bespoke Web applications for large enterprises and (naturally) ensured that they worked on the most popular browser of the time. Critically though, this was done without thought to how the code might perform in future, standards compliant browsers. In many cases, the code just wasn’t future proof.
As a result we have applications and systems which depend being viewed in IE6 in order to function. This represents a huge risk to many large companies who invested so heavily in their development, and have come to depend on the applications. It’s little wonder that they force their employees to use IE6.
Remember that this isn’t just the fault of IE6. There have been many poor browsers over the years, but thankfully, natural selection has let them disappear and allowed better browsers to take over. IE6 suffers from its own success. That is, it’s market penetration. Combine that with bad habits from developers and you have a browser which despite being left behind by evolution, is artificially kept alive by large enterprises as if it were on a magical life-support machine. I imagine that it would rather be left to die in peace.
Surely then, we Web developers have learned our lesson. We’re not going let something like that happen again are we? Staggeringly, after all the grumbling and pain, I see evidence that many of us haven’t learned our lesson at all. We still write code which detects which browser is being used, before going on to specify behaviour accordingly. What we should be doing is testing for the support of our chosen implementation, then implementing accordingly. Think object detection, not browser detection. That way, when a browser improves its support, or the user starts using a new browser, the application can enjoy the benefits, rather than just falling over.
I was particularly aggravated to learn how IE8 can be set to render as if it were IE7. With a meta tag to provide “Internet Explorer 7 Compatibility mode”.
<meta http-equiv="X-UA-Compatible" content="IE=7">
Why would this feature exist? Microsoft explain that it is so that developers can opt for “backwards compatibility with Internet Explorer 7 JavaScript and layout behavior”. In other words, it exists to try and get around the fact that so many developers wrote code to satisfy the quirks of IE7 without a thinking about how their code would fail when the quality of the browser is improved (have better conformance with W3C standards for HTML and CSS).
Microsoft didn’t want people to be resistant to upgrading to IE8 because of so many sites failing to render correctly in their shiny, new, more compliant browsers, so they provided a way to force the browser to continue to mis-interpret the code. I’m afraid I have to call “bull-shit” on this practice. I think that all this does is create another wave of Web sites and applications which are likely to get stuck in non-compliance land and require old rendering engines and legacy browsers to be kept alive to server them.
Only by developing for the rising tide of web standards, rather than the various quirks of specific browsers, can we hope to avoid locking our users in to a given browser. It’s time to make sure that we don’t get into this situation ever again. So next time you are tempted to grumble about IE6, remember that you can help avoid a similar mess in future by developing with standards in mind.
Sage words. But you’re quite right; and interestingly so, insofar as Microsoft have been doing this for years with releases of Windows. Various poorly known/understood, and undocumented APIs exist on versions of windows dating back as far as I can recall. This was done for commercial reasons, to allow significant partners and customers to maintain ‘compatibility’ with the new version of windows. Essentially, what this means is Microsoft, in their (arguably reasonable) drive for sales, pandered to the needs of ’special’ valued clients.
The fact that software developers take such offence to this almost precludes the raison d’etre of development which is generally to provide some piece of functionality to allow a business to perform more efficiently/profitably/better.
I suspect it may be exactly the same with IE8’s compatibility meta tag and all the other IE nonsense which preceded it.
Mozilla, Opera, Safari: underdogs at the time, didn’t have this ball and chain to carry with them. Now Mozilla are much less open to changing the Mozilla core; after all, who’d want to break the browser 3.5+ million people use? hence Mozilla Labs.
I suspect market forces will continue to perpetuate this behaviour for some time to come unless consumers as you say, vote with their feet.
[…] Phil Hawksworth makes some really valid points in his frank, well-considered post on Internet Explorer 6, arguing that web developers who locked companies in need to take some responsibility. While it’s poorly implemented and showing its age, many users simply don’t have the option of upgrading to more standards-compliant browsers. Read more here. […]
Hey Phil… Good to see this considered perspective on IE6 :) Blogged it at http://bit.ly/BibFq but guess pingbacks aren’t working. Anyway, definitely agree that those who created the problem in the first place need to take some responsibility… there’s nothing wrong with admitting that no-one foresaw the rise of Mozilla and standards compliance, but “it wasn’t me” doesn’t really work as an answer for me.
Guy,
Thanks for commenting. I agree with your suggestion that some of us didn’t see this coming (me included). There was certainly a time when I was contributing to the mess. I’ve created my share of Web applications which will be stuck in IE6 land now. I’m determined to try not to repeat that mistake with what I build these days though.
[…] of Web Browsers Creative agency mogul and Javascript whizz-kid Phil Hawksworth has posted a defence of IE6, arguing that in fact IE6 isn’t really as awful as we sometimes make out, and that its […]
Great post, Phil - I definitely agree with your basic points.
However, you seem to blame the lack of foresight solely on developers - yet we know that all too frequently, Management™ pushes through particular implementations, against the experts’ better judgment…
Quite right. Microsoft Engineers want people to upgrade [ http://blogs.msdn.com/ie/archive/2009/08/10/engineering-pov-ie6.aspx ], but contrary to some Web2.0 opinion ‘Nothing is Free’ [ http://www.state.gov/secretary/rm/2009a/july/125949.htm ] so we are indeed stuck with our own albatros.
FND,
That’s a good point. Pressures to deliver rapidly and at low cost often hamper the quality and robustness of code. While tough to do, I think that it is our (the developers) responsibility to make “The Management” aware of such issues and to press the importance of the point.
A little extra effort at this stage, can reduce the risk of exposure to greater cost and lock-in later on.
In fairness, anyone who’s been doing any sort of web development for more than a few years will have contributed to this… remember Geocities? ;) It’s just that some are (un)fortunate enough that their apps or websites have lasted past their sell-by date. I guess there’s also a good argument there that companies should get their asses in gear, accept that their websites/apps are outdated, and either move to an off-the-shelf package or commission another proprietary package which is standards compliant :)
5 years ago a majority of web developments pretty much ONLY had to target IE6. Many line of business apps, and development toolkits and frameworks pandered to this - the sorts of vendor-ware that enterprises insist that their development teams use. This only makes fixing the problem for apps that aren’t worth touching even harder, especially when often there is barely funding to cover support costs, let alone maintenance coders, let alone active development on a project. We may well need to wait until this evil spawn of standard-breaking apps that many enterprises rely on to run day to day business withers and is extinct before we can truly see the end if IE6. When will the cost of support XP/IE6 on the desktop be greater than the cost of replacing it?
[…] why is it still around? Phil Hawksworth makes a good point that it’s all about the enterprise. Large enterprises need to have their users locked in one […]
Hi Phil! I like the new perspective in wich you put this stale question. It seems more fair to me, and I also like the stress on accountability and future proof developing.
However, I’m not sure this can be accomplished in every situation.
For example, talking about the IE8 compatibiliy tag, I ask myself: could I really code for IE7 in a way of sure future compatibiliy with IE8?
I mean: sometimes we just move from some quirks, to other ones.
If a browser wrongly render a CSS margin of 10 pixel instead of 2, we can fix it. But what if the next version of that browser makes the same mistake, but with a margin of 5 pixel?
Similarly, I read about a couple of JavaScript bugs that appeared in IE7 and were not present in IE6.
Another question: what if a code conflict with a new browser feature? (IE8 Accelerators, for example) We can’t predict this.
If I think at “the old ages”, I remember IE6 was struggling to make developers adopt his own features, and the fight between W3C standards and IE-own-way was not a sure victory. What if other browsers adopted IE quirks instead of following W3C standards?
Anyway, even if our future guessing can’t be perfect, I absolutely agree it’s a good practice we should try to follow.
And, by the way, maybe I’m just writing this stuff to excuse myself from having used the meta compatibility tag… ; )
See you tomorrow.