Thoughts on the IE6 Upgrade Debate

Ah, Internet Explorer 6. That little workhorse with brain cancer that should have been put out of its misery years ago. Yes, I am one of the people who are in the camp that feels IE6 should have died with Netscape. I am a web developer, which means I am one of the many people that are expected to make a website work and look good on any of the major web browsers, and while that, thankfully, does not include such antiques as the defunct line of Netscape browsers, it does still include IE6.

Unfortunately, roughly 15% of users still use IE6, for various reasons (a few of which are, legitimately, beyond the end-user's control). It's these reasons that I'd like to address here, today.

This is a line I've heard from a number of hardcore IE6 lovers. These are the people that insist that they're just fine with IE6 and actively choose to not upgrade by declining the upgrade requests from Microsoft or reverting back from newer versions of Internet Explorer.

Thankfully, these people are relatively few and far between, making up for about 1% of the population that still uses IE6. Their rationale is still worth looking at, though.

Their idea is that most sites still look alright under IE6, though some will admit that some sites don't look perfect. Some of these people even attempted to upgrade to IE7, only to have issues with it, for some reason (the common complaints I have seen are IE7 crashing after a few tabs are opened, or just crashing in general), and thus returning to IE6.

The common factor in most of these people is that they only see the surface -- the presentation layer. They don't see what it takes to make the sites look even presentable in IE6. They don't see this because they are not developers themselves, so they don't look for them. They are the equivalent to the typical homeowner, while the web developers are the equivalent to the contractor that built the home. Where a homeowner sees another building with four walls and a roof, the contractor sees beams, wiring schemes, and structural integrity. The homeowner relies on the contractor to make sure that the underlying structure is sound and up to code.

The problem, though, is that IE6 is like a house with a termite infestation. It looks alright on the surface, but once you pull back the drywall, you find that the supports are eaten away so much that it's a wonder the house is still standing. These underlying problems can be seen by the professionals. In the case of IE6, that's the web developers, who have to work around IE6's shoddy standards-compliance and design-breaking bugs, and the more a developer wants to push web technologies, the more work s/he has to do to get it working on IE6.

The problem is compounded by the fact that there are enough people still using IE6 that when people want websites done, they want it to work on IE6, too. This means that the people making the website has to spend the extra time making it work in IE6. This is like adding more drywall to the walls of the termite-infested house to keep it up. The user doesn't see the real problem, because the contractor is expected to essentially hide it.

I actually saw this attitude on one of Microsoft's own websites, from one of Microsoft's own representatives, in the engineering section. That disturbs me.

Let me first do a little explaining about what validation is, exactly.

Every piece of code is written to some kind of standard. Desktop applications are written to the standards set forth by languages, such as C/C++, C#, Visual Basic, COBOL, and so on. Web applications are written to standards of languages such as (X)HTML, CSS (Cascading Style Sheets), JavaScript, PHP, and so on. In the case of desktop applications, which have to be compiled (converted to a language the machine understands, known as machine code) in order to run. If the code does not meet the standards put forth by the language's specification, then the program does not compile and cannot run, or will compile, but will present warnings if the code is technically correct, but not following best practices (which may cause issues while running the program).

Web applications are different in that they don't need to be compiled in order to run. You simply write your code, save it as a ".html" file (or whatever the appropriate extension is for the language you're using, the most basic is ".html"), then open it with a web browser and see if it works. The problem here is that browsers tend to be pretty forgiving about the code it renders. You can forget a closing tag in an XHTML 1.0 Strict document (all tags must be closed in XHTML Strict documents), but the browser probably won't call you on it and will happily render it, anyway. So, just because it renders in the browser you happen to use, it doesn't mean the code is up to the standards it should be.

Because the code isn't up to standards, it's very likely that while it works in, say Internet Explorer, it might render differently (or not at all) in other browsers, such as Firefox, Opera, or Google Chrome. Why doesn't it render the same across each browser? Well, it could be because each of the browsers have different rendering engines (the part that deciphers the webpage code). Or, it could be because you didn't write the code right. Any problem solver worth a grain of salt will start ruling things out by controlling what they can. The same should go for web developers, and since we can't (and shouldn't, at least to a reasonable extent) control what browser the user will be viewing our page on, we can control how well our code holds up to the standards, as defined by the creators of the language we're using. In the case of (X)HTML and CSS, the basic building blocks of all websites, the standards are defined by the World Wide Web Consortium, or the W3C.

Conveniently, the W3C has a code validation tool for both (X)HTML and CSS. You simply upload your code, or link to it from your website if it's already on a server that the tool can access, and let it run. The validation tool is not unlike the compiler for the desktop applications, it compares the code to the standards set forth by the language's specifications and makes sure that the document adheres to them. By making sure the code validates, you can then move on to the other possible causes of the rendering differences.

What does this have to do with IE6? Even with valid, well-written code, the chances are very good that IE6 won't render the page properly. This means that a web developer has to add another layer, often in the form of a separate style sheet specifically for IE6 (and sometimes other hacks, some that may keep the page from validating, which becomes a judgment call), hidden from other browsers using Internet Explorer's proprietary conditional comments, in order to get IE6 to at least make the page usable.

I've seen this come up a few times. Most often, it's with Windows XP users who haven't installed Service Pack 2, and therefore can't get IE7. Somewhat more rarely, it's with people who still use Windows 2000, which IE7 and later won't install on at all, ever. In other cases, not necessarily related to the operating system, but rather the hardware itself isn't capable of running newer versions of IE (this is often the case in corporate or educational settings, where the IT department has to make computers last for ten years or more).

To that, I say, stop using Internet Explorer altogether, then. Firefox will run on Windows 2000 and Opera runs surprisingly well on even an ancient Windows 98, Pentium II system. This would allow the user the security of a modern browser, while not requiring major upgrades to the computer. Obviously, in a corporate or education setting, this would require IT to install the software on the computers, as well as some time training users, but those in that situation are not without options.

This problem is exclusively an organizational one (in other words, individuals on home computers don't have this problem). In my experience, the organization either has a network security system that newer browsers can circumvent (because the security system was likely designed only for IE6, in the days when it was the only viable browser available), or the companies intranet was built with software or on a Content Management System (CMS) that only works with IE6 and will break if viewed with any other browser.

This group, especially when it falls into the first subgroup (network security measures requiring IE6), doesn't often have much effect on the Internet, for the simple fact that most of the sites that have the worst trouble supporting IE6 (AJAX-heavy web applications, such as GMail, or rich media and social networking sites, such as Digg or Youtube) are often banned under these same security protocols. Basically, this subgroup only has a browser on the computer at all because it's a part of the operating system and can't actually be removed.

The second subgroup generally finds the idea of upgrading, or even installing an alternative browser, which can sit side-by-side with IE6 (as opposed to newer versions of IE, which can only overwrite the previous versions, unless you know where to get standalone installs), to be too daunting and potentially very costly in both training and technical problems that inevitably arise, particularly when the company is maintaining several thousand computers. The issue compounds when the company also relies on an intranet application that breaks under any other browser. This fear (and subsequent reluctance to upgrade) is certainly an understandable one, but is still one that will need to be faced sooner, rather than later.

IT departments generally do computer upgrades in waves. They may upgrade a third or a tenth or another fraction of their computers each year or half-year, depending on the number of computers in the company. This will inevitably result in computers that can't run IE6 anymore. Even if they have a deal with their vendors to "downgrade" to Windows XP on their new computers, this will only last for so long, especially after Windows 7 officially releases and becomes the default install on all Windows computers, and Windows XP reaches the end of its support lifecycle. Win7 is simply not capable of running IE6 without the use of a virtual machine with Windows XP (I've tried). The problem of jerry-rigging a new computer to run IE6 will just continue to worsen as we move farther and farther away from IE6's lifecycle support end date (which is currently set to July, 2010), eventually forcing even the most reluctant IT departments to upgrade.

Yes, this is one I have actually heard. What it's referring to is the blindingly fast pace at which technology advances (this is known as Moore's Law, where technology doubles roughly every two years), and the techno-enthusiasts who attempt to keep up with it. These are often the "early adopters" of various forms of technology. This is a somewhat understandable concern, albeit an inaccurate one in this case.

Internet Explorer 6 released in late 2001, while Internet Explorer 7 was released in 2006, and Internet Explorer 8 in 2009. The smallest time gap between these releases is three years. Even skipping every other release, that would put roughly five years between upgrades. That falls well outside the realm of "enthusiast."

With the large variety of browsers available to users and the advancements made in the newer browsers that provide a richer browsing experience, it's a wonder why such a large percentage of people still hold on to Internet Explorer 6. Hopefully, there will eventually be enough incentive, especially for reluctant companies, to upgrade to a newer browser.