Too Funny - An IE7 Tax

An Australian online retailer has started charging users of IE7 a tax to use the browser on their website. This was inspired, they say, by the amount of time it took their developers to make the site work correctly with IE7 (which 3% of their users were still using). The tax is currently 6.8% — 0.1% per month since IE7 was released.

Presumably they just aren't supporting IE6 at all — if they did, the tax would be a whopping 13% (at the moment).

IE6, the Undead Browser

2013/05/16: Ah, what a difference a couple of years makes. :-) Today, this article can be a lot shorter, and could be titled "IE6, the Mostly Dead Browser". Huzzah!

Is IE6 finally dead?

• In China: No, it's still more than 24% of the browser share there.
• Everywhere Else: Yes!

I can't give the region-by-region breakdown I could below because Net Applications have started charging (a lot) for that report, but even in places like Mexico and India, which had high IE6 use a couple of years ago, use has plummeted. According to ie6countdown, after China, Taiwan is next at 3.5%, followed by India at 2.8%, and then Japan and Russia tied at 1.7%. The corporate U.S. finally "got" the security risk and has moved on to IE8 or IE9.

The take-away? If you're developing web pages and web apps for China, you must still support and test on IE6. By all means include an educational banner or something advocating change, but you must still support it. Just about anywhere else, fergedabouddit.

And what about IE7? Great new there: Worldwide usage of IE7 is currently just 1.81%. So people leaving IE6 jumped to IE8 (23.08%) or IE9 (18.17%) (and those nearly 20% at one point who were using IE7 have moved on too). We can figure a lot of those IE9 users will soon be on IE10. The IE8 users will be with us for a while, since that's as high as Windows XP goes.

Here's the old article from October 2010 (with updates in November 2010 and March 2011), just for posterity:

---

2011/03/14: See also Microsoft's new IE6 countdown site

2010/11/18: Updated to also reference StatCounter's figures (for May 2010).

There's a common refrain on sites where people ask for help getting things to work well cross-browser, when someone mentions needing to support IE6:

IE6 is dead. Microsoft officially stopped supporting it. I don't see any reason you should.

— comment from a StackOverflow user

IE6 is dead. don't speak of it.

— another StackOverflow comment

Some people have even held a funeral for it (Microsoft were classy enough to send flowers); others declare it Well and Truly dead.

So is IE6 finally dead?

No.

Far from it, IE6 is still (as of this writing) the third most used browser out there, at 15.55% it's just barely behind Firefox 3.6 at 17.05%, both trailing IE8 at 29.06%. (That link is for September 2010; current stats here.) StatCounter gives a slightly lower figure, making it the fourth most popular browser in the world at 9.75% in May 2010 —which makes sense; StatCounter and Net Applications have different customer bases.

Like most developers who do browser-based applications, I wish IE6 were dead. It certainly should be, and Microsoft are doing everything they can to kill it, but unfortunately it's not quite that simple. IE6 was the de-facto standard browser in large corporate and government environments for the majority of the boom of browser-based applications, and therein lies the problem. Large organizations are very slow to upgrade key bits of software. For example, many of us recently petitioned the UK Government to upgrade all government departments away from IE6. Their response was to say that it's "...not straightforward for HMG departments to upgrade IE versions on their systems...", that testing their web apps for compatibility "...can take months at significant potential cost to the taxpayer..." and that they deal with the security issues with firewalls and malware scanners. Big business is much the same as big government in this regard. You can bet that the majority of users of IE6 are sitting in a cubicle somewhere.

It's also interesting to try to find a statement from Microsoft backing up the assertion from our first commenter above that IE6 is no longer supported by Microsoft. Some point to the Lifecycle Supported Service Packs page saying that it says IE6 support ended on July 13th, 2010, but that page is about service packs, not products, and the July 13th date is only listed next to some of them; others, like the one for IE6 on Windows XP SP3 say that support ends 24 months after the next service pack is released. There hasn't been an SP4 for XP and SP3 is still supported (support for SP2 ended on the aforementioned July 13th), so... Further, that page also (now) says it's "no longer updated and scheduled for retirement," referring people to the Microsoft Product Lifecycle Search page instead. Amusingly (or perhaps I'm just laughing to hide the tears), if you use that page to find lifecycle information for Internet Explorer 6, it doesn't give an end date for extended support; instead, it says "For support dates for specific Internet Explorer 6 and operating system versions and their service packs, visit the Lifecycle Supported Service Packs site at..." Yup, that's right, they then give our first link above, the one that says it's no longer maintained. Rinse, repeat. So has Microsoft ended support for IE6? If so, those pages aren't saying so.

So what does this mean for those of us who develop web sites and applications? Well, your first thought might be that if you're writing a consumer-facing website, you can probably drop support for IE6. And that's probably mostly true, although you have to consider what it could mean to lose people browsing on their lunch break (or any time the boss isn't around) when most sites are scratching for every hit they can get, antiquated insecure non-compliant browser or no. You also have to consider where your visitors are coming from; StatCounter says that IE6 use is half as likely in the U.S., Europe, the UK, Canada, Australia, and New Zealand, where in all of those except Australia they're seeing numbers under 5% and in Australia only just barely over (as compared with 9.75% worldwide). But even StatCounter is seeing IE6 as the second-most popular browser in Asia at 20% and the top browser in Africa at 22%. So the locality (if any) and language of your site play a part.

But even in those ~5% countries, if you're building software that you want corporations to be able to adopt, I'd say that right now, today, you ignore IE6 support at your peril. Unfortunately. Maybe in another year, although with the downturn, IT budgets are pretty tight...it may take even longer than that.

There is good news, though. This time last year (September 2009), IE6 was the number one browser, at 24.42% dominating IE7's 19.39% and IE8's 16.84%. So clearly on the way out. I predict the decline will continue but flatten out as we hit the hard core corporate deployments with strapped IT budgets. (The other good news in comparing last year to this year is how IE7 is being displaced by IE8. Excellent. IE8 is a much, much better browser than either IE6 or IE7...and if people are willing to upgrade, when the time comes maybe they'll keep going to IE9.)

Happy coding.

A literal improvement

JavaScript literals are getting better. Until recently, the grammar for object literals didn't explicitly allow a trailing comma, like this:

var obj = {
    foo: 42,
    bar: 27, // <== This is the problem
};

SpiderMonkey (Firefox), V8 (Chrome), and whatever Safari and Opera use don't care, but JScript (IE) prior to JScript 6 (IE8) throws a parsing exception on the comma and your script dies. (JScript 6 / IE8 fix this.)

A trailing comma in an array literal has a different issue:

var a = [1, 2, 3, ];

All versions of JScript so far (including JScript 6 / IE8) create an array with four (yes, four) entries, the last of which is undefined. This isn't unreasonable, because the spec wasn't explicit about it and we were always allowed to have blank entries (e.g., var a = [1, , 3];) and those entries defaulted to undefined — but everyone else went the other way and created an array with three entries instead.

Fortunately, ECMAScript 5 clears this up. The trailing comma is explicitly allowed in object literals (Section 11.1.5), and in array literals (Section 11.1.4). In the case of array literals, the trailing comma doesn't add to the length of the array (a.length above is 3).

The team behind IE9 are very engaged with standards bodies now, so hopefully that includes the JScript folks and they'll change the array behavior, though you know it must be a much harder sell for them than the object literal was — it involves changing the behavior of something that did work. Still, here's hoping.

Double-take

There's an issue with Microsoft's JScript interpreter (the one used by IE, Windows Scripting Host, and others) that you see mentioned deep in discussions of other things. I thought it would be worth just briefly talking about on its own.

Update: The newer version of JScript used by IE9 and up doesn't have this bug anymore. Yay! Still in IE8 and earlier, though.

Basically, if you use a named function expression in your JavaScript code, JScript will process it twice, creating two separate function objects, at two separate times: First it treats it as though it were a function declaration (even though it isn't), and then it treats it as the expression it is. This is not a distinction without a difference, either, as we'll see below. (Amongst other things, it creates "symbol bleed," putting the function's name in the enclosing scope in clear violation of Section 13 of the specification, which says that it should only be defined within the function's own scope).

What do I mean by function declaration vs. function expression (named or otherwise)? Here's a function declaration:

function foo() {
}

Here's an anonymous function expression:

var foo = function() {
};

And here's a named function expression — this is the one JScript (IE) has an issue with:

var f1 = function foo() {
};

The easiest way to tell whether you have a declaration or an expression is to ask yourself: Are you using it as a right-hand value? E.g., are you assigning it to a variable/property or passing it into a function as an argument? If so, it's an expression. If it's standalone, it's a declaration. Here are some further examples of named function expressions:

bar(function foo(){});

var obj = {
    nifty: function foo() {
    }
};

So first off, how do we know JScript is creating two function objects? Here's the easiest way:

var f1 = function foo() {
    alert(f1 === foo); // alerts "false" on IE, "true" on other browsers.
};
f1();

So, okay, but what do we care? Well, let's say you want to hook up an event handler and have it unhook itself later if some condition is met:

Prototype example:

$('foo').observe('click', function fooClickHandler() {
    if (/* ...some condition... */) {
        this.stopObserving('click', fooClickHandler);
    }
});

jQuery example:

$('#foo').click(function fooClickHandler() {
    if (/* ...some condition... */) {
        $(this).unbind('click', fooClickHandler);
    }
});

Perfectly reasonable, but won't work on IE. The handler will remain attached, because when you unhook a specific event handler, the function reference you give has to be the same as the reference you want to remove. On IE, the above, it isn't: fooClickHandler isn't the same function that we hooked up. The expression returned a different function.

So how do you work around it? Just make sure you're using declarations, like this:

Prototype example:

function fooClickHandler() {
    if (/* ...some condition... */) {
        this.stopObserving('click', fooClickHandler);
    }
}
$('foo').observe('click', fooClickHandler);

jQuery example:

function fooClickHandler() {
    if (/* ...some condition... */) {
        $(this).unbind('click', fooClickHandler);
    }
}
$('#foo').click(fooClickHandler);

If you don't want fooClickHandler to be a symbol in that scope, wrap it up in a scoping function, like so:

Prototype example:

(function() {
    function fooClickHandler() {
        if (/* ...some condition... */) {
            this.stopObserving('click', fooClickHandler);
        }
    }
    $('foo').observe('click', fooClickHandler);
})();

jQuery example:

(function() {
    function fooClickHandler() {
        if (/* ...some condition... */) {
            $(this).unbind('click', fooClickHandler);
        }
    }
    $('#foo').click(fooClickHandler);
})();

Alternately, you could just not use names (and use arguments.callee to unhook the handler), but there are lots of good reasons not to do that (arguments.callee is slow on most browsers, not allowed in ECMAScript's new "strict" mode, and besides, names are good).

So what's this "symbol bleed" issue I mentioned? Well, according to the specification, the scope of the function name in a function expression is confined to the function itself, not the encompassing scope. So:

var f1 = function foo() {
    // `foo` is defined here
};
// but not here

Whereas, of course, if that were a function declaration, the foo symbol would (of course!) be defined in the scope in which the function is declared.

(You can see this coming, can't you?) Since one of the times IE processes the named function expression it treats it as a declaration, it incorrectly defines the symbol in the enclosing scope — much like we would do if we didn't use the scoping functions above — which is incorrect.

Happy coding!

...by any other name, would smell as sweet

Although it's not a new problem, lately I've been seeing so many people running into a specific issue with Internet Explorer that I thought it worth just jotting down what the problem is and how to get around it.

The problem, in brief, is conflation. Internet Explorer (v6 and v7) mixes together the namespaces of the id and name attributes, which should be completely distinct from one another. id, you'll recall, must be unique within the document; it uniquely identifies an element. name, on the other hand, is not for uniquely identifying things (well, not mostly). It's used for a couple of different things, such as giving form fields the names they'll have when submitted, or giving anchors a name. There's no requirement that name values be unique — in fact, when doing forms, there are lots of reasons for using the same name for multiple fields (radio buttons, for example).

Unfortunately, the Internet Explorer engine will find elements by name sometimes when it really shouldn't, specifically when you're using document.getElementById. So for instance, say you have a form in your document with a 'stuff' field:

<input type='text' name='stuff'>

and later in that same document you have a div with the id "stuff":

<div id='stuff'>...</div>

Consider this code:

var elm;
elm = document.getElementById('stuff');
if (elm) {
    alert("The element's tagName is " + elm.tagName);
}
else {
    alert("Couldn't find the element.");
}

In a browser that implements document.getElementById correctly, that should alert "The element's tagName is DIV". But on IE, it will alert "The element's tagName is INPUT" because it incorrectly finds the input field. The only way around this is to change the id or name of one element or the other.

Another related problem is that id values are not case-sensitive in IE6 or IE7, although of course the standard says they should be. So it'll also confuse an element with the id (or name) 'stuff' with one with the id (or name) 'Stuff'. (To be fair, surely you and I would as well?)

There's good news, though: Microsoft does document the behavior, and they've fixed it in IE8, so there's hope for the future.

Perhaps slightly OT, but lest people accuse me of Microsoft-bashing (er, I have been known...), let me just remind everyone who brought us XMLHttpRequest (the basis of Ajax) and innerHTML, both of which I use (directly or indirectly) in nearly every JavaScript-enabled browser project I do — and I bet you do too. So hey, they got many things wrong, but got some things very right as well. Also useful to remember — as we continue to bash IE6 with repeated shouts of "Die! Die!" — just how much amazingly better (faster, less crash-prone, more feature-rich) it was than its chief rival, back in the day.