Tagged: IE6

SolutionSet has been carefully watching the browser market share for IE6 and there’s a promising trend: IE6 has lost more than 1% of the market every month in 2009. With only 5% of the market in the United States, IE6 now has fewer users than the latest version of Safari and an old version of Firefox. Globally, IE6 is faring much better, but even with 13% of the market it still dropped the same 1% per month that it did in the US. It will be interesting to see if the trend continues throughout 2010. Keep an eye on the Windows 7 market share as an indicator of what’s in store for IE6.

This news means that SolutionSet is now ready to phase IE6 off our list of browsers we support. Unless a project has IE6 as a specific technical requirement, supporting IE6 should be seen as an additional development cost that could potentially be avoided. Already it makes sense to deliver a degraded experience to IE6 for certain design elements such as rounded corners and drop-shadows. As major corporations start the slow upgrade to Windows 7, 2010 is shaping up to be the year that IE6 finally becomes a thing of the past.

IE6 has inspired a fair amount of ire within the web development community, largely because of its age. When IE6 was created, Microsoft was blessed with a lack of competition; check out the usage statistics from 2002 and 2003. Adding to the tension is the fact that all of the various versions of IE have had their special kind of CSS display weirdness (I can’t remember ever having to worry about a new version of Firefox breaking all of my websites). While the days of supporting IE 5.0, IE 5.2.x for Mac, IE 5.5 and IE 6 all at once are over, there’s still three very different versions of IE in use today. Over the last several years all traces of IE5 have all but vanished from the Internet while IE6 is still going strong.

But now the browser landscape has changed and Microsoft moving strongly towards standards support and there is a much more diverse marketplace than there was in 2001. With the pending release of Windows 7, the recent releases of Firefox 3.5 and Safari 4, and the coming utopia — or not — of HTML5 and CSS3 there’s a renewed interest in killing IE6. This is actually a great opportunity to start moving web technology forward — especially with the vastly improved JavaScript performance of the latest browsers — but IE6 will likely be around for a little while longer.

Recently DIGG posted a fantastic article on their blog that proved our anecdotal hunch to be correct; IE6 is still around because of corporate users that are mandated to use IE6 by their global IT support team. The most interesting portion of their article showed that nearly 70% of the people still using IE6 are forced to use it while at work. Many companies spent significant amounts money on systems that relied on ActiveX controls (and other proprietary IE6 technology) for internal web applications and now upgrading is an expensive proposition (I recently did work with a company that requires IE6 to connect their corporate VPN). The DIGG article rightly concludes that, “this goes directly to why most folks use IE6: they don’t have a choice. [Asking them to upgrade] in this case is not only pointless; it’s sadistic.”

While it’s sadistic to force corporate users to upgrade IE6, many developers are starting to question the real costs of developing for that browser. Many high profile sites — with little need to support corporate visitors — are already dropping support. It’s going to make sense for companies to start charging for the privilege of supporting IE6.

Many development firms are discussing the possibilities of reducing or even dropping IE6 support in the coming year or at least charging extra for IE6 support. This will likely come in a few flavors:

•  Full Compatibility — Doing full QA in IE6 and altering the design requirements to ensure full IE6 compatibility and charging a premium for that service.
•  Reduced Display — Removing things like rounded corners, drop-shadows, alpha-transparent PNG’s in IE6 (They’ll still show in other browsers) that take extra time to support. But making sure that the site is usable in IE6.
•  Reduced Functionality — This includes reduced display and throws in a reduction in AJAX and JavaScript functionality while ensuring that the site is usable.
•  No QA at all — Not even looking at the site in IE6 and hoping for the best.

A lot of the fixes to make IE6 act like other browsers require JavaScript and IE6 is almost 10 times slower than modern browsers which just adds to the pain. The most sensible thing is to design for a reduced IE6 display, removing drop-shadows and rounded corners and other visual eye-candy. Without removing some of the visual bells and whistles the IE6 user experience is almost unbearable as page loads are significantly slowed by extra JavaScript execution ironically designed to make the experience better.

The beginnings of HTML5 support are already on the market in the most recent round of browsers and CSS3 support is on the way. The limitations of IE6 are becoming a hindrance to progress in the web development world. SolutionSet will be able to better serve the needs of our clients by phasing out IE6 support except for the projects that absolutely demand it. While the predicted adoption rate for Windows 7 is currently bleak, those reports are, in my opinion, wrong. Microsoft likely is not going to allow new hardware to be sold with Widnows XP after Windows 7 is released. On top of that, Windows 7 allows users to run XP programs which will in turn allow them to continue to use IE6 in Windows 7. But the important difference is that IE6 will no longer be their default browser; they’ll have IE8 (and in Europe they’ll have whatever they want).

Over at ryanbrill.com, I’ve previously written about the multiple class bug in IE6. Today, we’re going to look at another similar IE6 bug: the ID-Class bug.

It seems that IE6 chokes when you have an element with an ID and several different class states. A common example is when you add a page class to your #content div. Take this example:

Home page:

<div id="content" class="home">
	<p>Home page</p>
</div>

About page:

<div id="content" class="about">
	<p>About page</p>
</div>

CSS:

#content.home {
	background: blue;
}
#content.about {
	background: red;
}

Given that code, IE will only ever add the styles to the #content.home div. #content.about or any subsequent styles following the #id.class paradigm will not get applied. Note that the order of the classes in the CSS is key here. If you move the #content.about rule above the #content.home rule, then the #content.home rule will no longer work.

So, how to fix this?

There are two options. The easiest one is to simply remove #content from the selectors, leaving you with:

.home {
	background: blue;
}
.about {
	background: red;
}

This may not necessarily be the best solution, as now you have generic classes that could be applied elsewhere (for instance, <a href="index.html" class="home">).

That brings us to another key part of this bug. This is only relevant if the #id.class is the last item in the selector. So, another option is to move the class higher up in the source, perhaps to a #container div:

#container.home #content {
	background: blue;
}
#container.about #content {
	background: red;
}

That will work fine, as the #id.class is no longer last in the selector. This is the solution I recommend, as you won’t have to worry about a generic class being added to un-intended elements.