Phasing out IE6

37signals is phasing out support for IE6. The company weblog lists the reasons for this decision, including:

IE 6 is a last-generation browser. This means that IE 6 can’t provide the same web experience that modern browsers can. Continued support of IE 6 means that we can’t optimize our interfaces or provide an enhanced customer experience in our apps. Supporting IE 6 means slower progress, less progress, and, in some places, no progress. We want to make sure the experience is the best it can be for the vast majority of our customers, and continuing to support IE 6 holds us back.

Those are excellent reasons, and ones we should be taking to heart. At issue, though, is the fact that Microsoft has made it very difficult to eliminate IE6.

When Microsoft rolled out IE7, it did so only in newer generation operating systems, such as Windows XP and Vista. This left a large contingent of users of IE6 on Windows 2000, which is still in fairly wide use. The company also didn’t post recommendations for W2K users to switch to a different browser, such as Firefox or Opera. Both actions served to leave a bloc of orphaned IE6 users, many of whom are still haunting our web sites.

I also don’t give much credence to those bemoaning the burden that dropping support for IE6 would have on corporations, libraries, and schools. It is not an onerous task to install Firefox on people’s machines. Nor is it an impossible task for sites to update their software. If two years since the release of IE7 isn’t enough time, what is the right amount of time? Five years? Ten? At some point, we’re faced with biting the bullet, and doing so before IE8 is released seems to be a good time to crunch down.

The single biggest hindrance to expansion on the web today is IE6. We can’t use transparent PNGs because of IE6. Anything but the most rudimentary uses of JavaScript becomes a problem with IE6. Our sites are full of workaround CSS and page markup existing only to support IE6. We are, in effect, grand prix racers stuck behind some old cow left in the road by farmers who have decided they like pigs, better. Oink.

I don’t support IE6, and not just because most of my readers are using new browser versions. I don’t have a separate machine I can keep at IE6 in order to test my pages. Since we can’t run IE6, IE7, and IE8, simultaneously, I made a choice to support the two newer versions of IE, which are, themselves, enough of a challenge. For the older browser users, I provide the printer friendly pages with all JavaScript and CSS stripped out. It may not be an optimum solution, but neither is supporting IE6 until all the older machines are piles of rust.

I do hope that 37signals begins a trend.

(via Simon)


As Ralph points out in comments, yes we can use PNGs with IE6, if we use IE specific filters. I’ve not had the best of luck with IE6 and PNGs, and typically just hide my PNGs from IE6 with CSS. But then, I decided with the first beta of IE8 that I was not going to create specific code for IE6 any longer. Two versions of any browser is enough.

Ralph also notes the PNG8 workaround for IE6. However, using this technique does not ensure that an image is going to look as good in IE6 as it does in other browsers. I’ve not tried this with GIMP, and I don’t have a version of IE6 for testing, but is an option for those still having to support IE6. However, as the Cozi Tech Blog mentions:

We have since decided that we will no longer make heroic efforts to get our web application looking just as good on IE6 as it does in modern browsers. Quite apart from the extraordinary amount of pain we endured in the Affair of the Transparent PNGs, fighting with IE6 has been a huge timesink for us, especially when it comes to working around its CSS bugs.

A significant fraction of our users are still using IE6, so we have no choice but to support it. However, we no longer aim to achieve full parity.

If sites still support IE6, but at a minimum, as I do with my sites, this also may finally force the issue and hasten the EOL for this browser.


Shiretoko: First Looks

I downloaded the first alpha of Shiretoko, or Firefox 3.1, and I’m delighted to see the text-shadow I have attached to my site name showing up in a Firefox browser.

Not just text-shadow, Mozilla has also added JavaScript query selectors to this release, which means that we can query for all elements of a given class name, such as:

var list = document.querySelectorAll(".elements");

A behavior that we also had with the older, supported, document.getElementsByClassName. However, we couldn’t do the following with getElementsByClassName:

    var first = document.querySelectorAll("div > p:first-child");   
    for (var i = 0; i < first.length; i++)   {    

This code snippet accesses the paragraphs that are directly the first child of any div element, using the CSS selector syntax, and sets the background of each returned element to red. You can see it in action with this simple example containing three div elements, each with three paragraphs, the first of which now has a red background. Well, you can see it with browsers that support querySelectorAll, which are Safari/Webkit, IE8, and now Firefox 3.1a. Opera has also committed to the support of querySelectorAll (as well as rgba, we hope).

Of course, I can do something like this with JavaScript by getting all div elements, and then all paragraphs of all div elements, and then accessing the first of the returned set, but how much simpler, and how my more robust will this process be if this type of functionality is built directly into the browser. Especially since my example is quite simple, but other queries on CSS selectors could be quite complex.

Firefox 3.1a also has support for border images, which means no more nested div elements to achieve specialized borders, which is what’s used in the design of this site. However, support for this CSS3 attribute is limited to Firefox 3.1a and Safari; until support for the option reaches three of my four target browsers, I won’t use it for my site designs.

(I felt comfortable using the text-shadow when only Opera and Safari supported the CSS attribute, because it provides such a nice effect, which degrades beautifully if the attribute isn’t supported.)

Firefox 3.1a also supports the HTML5 Canvas Text API, but I haven’t had a chance to play with the new capability, yet. I had rather hoped that the Mozilla team would add a little SMILe to the browser, but I guess it’s not to be with this browser release. Perhaps our man on the SVG street, Jeff Schiller, can update us on a SMIL timeline for the browser.

Oh, and look: anyone can try the browser and report a bug.


You can stuff your bug

In reply to the IEBlog web post that is asking people to apply for the right to submit a bug:

Why, on earth, when other browser developers provide open and easy to use bug systems, would Microsoft limit itself in this way?

I have a bug in Webkit, five minutes can help me determine if someone had already reported the bug; no more than another five to submit the bug, with test case.

Mozilla created software to make it easy to search on, and submit bugs. Why, I bet even you all could use it.

Opera has a handy, dandy bug form that makes bug submission a snap.

And here is the IE team “If you email us and ask us really nice we may, just may, mind you, deign to let you actually tell us about that bug, which if left in the released product will haunt us until the end of time. If you don’t ask nice, you can stuff your bug.”