Supporting Internet Explorer 6: a problem-solution approach

Microsoft has announced that Internet Explorer 6 will be still supported until 2014. It seems that web developers should face the same problem occurred with Internet Explorer 5 (both Mac and Windows versions). This is a long term support: two years on the web are an eternity. Despite the fact that many developers have decided to bring down IE 6, this is not a feasible and practical approach, at least until IE6 won't have a significant market share. Here "significant" means more than 5% of the market share, that is, a small but still relevant percentage.

Supporting Internet Explorer 6 means working at most on the client side. Concerning this aspect, there are two standards that are worth of being considered more than others: CSS and JavaScript. Let's see how to tackle these two problems.

CSS support in Internet Explorer 6

The CSS support in IE 6 is absolutely buggy and incomplete. It's buggy, because it's heavily affected by the hasLayout property and it's incomplete, because it doesn't feature some advanced CSS properties and selectors, such as:

  1. :before, :after, :first-child and all the new CSS 3 selectors
  2. :hover on all elements
  3. opacity, multiple background images, min/max width/height, etc.
  4. fixed background images on all elements
  5. CSS 3 properties

The most obvious solution to this problem is to use JavaScript to mimic these features, for example by using jQuery to make IE 6 support the most advanced CSS selectors. Most CSS purists don't like this idea, but I think that they should consider the fact that they can't change the default behavior of IE 6 only with CSS, simply because IE 6 doesn't understand CSS very well! Further, another problem may arise: the overuse of CSS classes to apply styles to some elements that could be otherwise matched with CSS selectors, like this:

h2 + p {
    font: italic 1.2em Georgia, serif;
   color: #666;
}

If you don't use JavaScript, you have to add a class within the markup in order to make the above styles work. If you follow this approach, you'll probably end up with dozens of classes within a single document! Instead, you can avoid this simply using a single jQuery statement:

$('h2 + p').addClass('first');

In this case, you keep CSS styles and markup separated, without worrying about generating a class attribute on each paragraph that follows a level-two heading. Do more with less: this is the jQuery's motto.

JavaScript support in Internet Explorer 6

Same story as for CSS: IE 6 JavaScript support is buggy and incomplete. What's worse, IE 6 features the slowest JavaScript engine among the other browsers. To mitigate this problem, follow the good advice of Yahoo!'s developers: put your scripts at the bottom of the page, like so:

<body>
<!-- page content -->

<script type="text/javascript" src="library.js"></script>
<script type="text/javascript" src="my-script.js"></script>
</body>

I soon noticed significant improvements during page loading, because now the document body and scripts are parsed and fetched together. The other problem is related to the native implementation of JavaScript used by IE 6: in fact, this browser shows a curious mix between the ECMAScript standard and its proprietary jScript language (IE's implementation is actually stored in the jscript.dll library). The resulting implementation is actually inconsistent, mainly because most parts of the recent ECMAScript versions are not supported. Further, DOM implementation is incomplete and buggy: IE 6 shows significant problems even with the Level 1 of this standard. In addition to these problems, this browser uses a proprietary approach to some features of the DOM, like event handling.

Again, a good solution to these problems is using a JavaScript library to fix (or at least to mitigate) the aforementioned incompatibilities and inconsistencies, though in some cases this is not always possible.

Supporting legacy browsers

I don't have access to the browser stats related to my web sites, so I have to get this kind of information from another source, such as search engine sites or page ranking services. The problem with these sites is that they provide only information about the number of visits within a given time range.

However, these sites also report the geographical area my visitors belong to, and I have to say that this kind of information is very useful. I've found out that the majority of my visitors come from Italy (about 60%), followed by a significant number of English and American users who share the remaining 40%. That's fine, but the underlying problem remains the same: I don't know what kind of browser they use.

Since my sites are about web standards, it's likely that my visitors may use a full standard compliant browser, such as Firefox, Safari or Opera. That's true if we consider my visitors only as colleagues, but it might be false if we take into account also clients. In fact, clients may surf the web with a legacy browser (Internet Explorer 6, or even worse) and when they find your site broken, they may think: "so you're a web developer, huh? Fix your own site first!".

In that vein, I followed a radical approach with CSS Zibaldone by keeping structure and layout as simple as possible. The result is practical but ugly: don't follow my example if you want to get some interesting jobs! So I decided to create a stronger structure and a finer layout for this web site. To accomplish this task, I wrote down a practical browser testing order, which includes:

  1. Firefox
  2. Internet Explorer (6, 7, 8)
  3. Others (Safari, Opera, Camino, etc.)

The order is relevant: when I test a site, first I view my results in Firefox, then in Internet Explorer and finally (only finally!) in Safari, Opera, Camino, etc. Supporting legacy browsers such as IE 6 means only one thing: testing, testing, testing!

As a rule of thumb, never trust the results achieved on your local machine, because IE behaves differently on a remote server (this is particularly true for Ajax and any XML-based language). And remember: test first, fix later.