The JavaScript blog.


browser ie chrome dojo

Dropping Legacy IE Is No Panacea

Posted on .

The presiding sentiment of client-side developers seems to be that dropping legacy IE support fixes cross-browser issues. While it does reduce a lot of rendering quirks, it doesn't mean you can stop browser testing altogether.

The reality is that there are four popular browsers with a wide range of versions. Using DailyJS's readership during August as an example, Chrome's versions break down like this: Chrome 28 has 53%, and Chrome 29 is at 13%. Firefox has 43% on version 22 and 41% on version 23. That means we see very few Firefox and Chrome readers on older versions, so they're doing an excellent job of keeping users up to date. Digging into the IE stats, I can see 50% using IE 10, and 0.33% on IE 6!

Why am I bothering you with browser stats? It was because I saw this bug in Dojo earlier today: #17400: Chrome 29 breaks dojo.query in Dojo 1.4.4 through Dojo 1.6. The Dojo developers quickly fixed the bug. It seems someone had used array-style accessors on a DOM node instead of the children and childNodes properties.

Even though IE 10 is far better than its predecessors, and Chrome and Firefox see fast upgrade rates due to their update mechanisms, you can't leave out proper cross-browser testing. It's hard work and dull, but unfortunately still important. I have a feeling the disparity in mobile browser technology will be the new IE 6, but that's another story...


tutorials frameworks lmaf ie

Let's Make a Framework: IE Testing

Posted on .

Welcome to part 45 of Let's Make a Framework, the ongoing series about
building a JavaScript framework.

If you haven't been following along, these articles are tagged with
lmaf. The project we're creating is called Turing.

IE Testing

The way I usually test my projects in IE is with
IETester. I actually run this in a virtual machine, just to be safe. Some of my clients still
require IE6, some are on 7, and I usually test in 8 and 9 as well.
Supporting IE6 is usually the most difficult thing to do, but I usually
find JavaScript debugging less painful than design glitches.

I opened IETester and tried running Turing's tests in IE6 and found they
didn't run. That's... just life, isn't it?

To focus a little bit more I tried a simple unit test instead of the
whole set. The
alias_test.html seemed like a simple one. It produced this error:

It's probably something to do with the slightly ambitious CommonJS
module style test system we created. Note that you can press the escape
key to quickly close these IE popup Windows. I tried removing the
alias_test.js script and the error didn't appear, which means there isn't a problem parsing the files that the test depends on.

After commenting out the code in the test itself, I figured out
require was failing somewhere. I used the IETester debug
tools to run require('') and the same error popped up. The
problem was here, in the Turing Test library:

head[0].insertBefore(scriptTag, head.firstChild);

IE Script Loading

At this point I found IE wouldn't attach load events to
script tags. I dimly recall something about this from Dean Edwards'
posts on window.onload

This is the kind of issue we had to deal with until the post web 2.0
revolution, but I came up with a scheme to use setInterval
to watch for changes on readyState on script tags. This
will work in IE, but not in anything else. That gave rise to this:

function loadIEScript() {
  var id = '__id_' + (new Date()).valueOf(),
  scriptTag = document.getElementById(id);

  timer = setInterval(function() {
    if (/loaded|complete/.test(scriptTag.readyState)) {
  }, 10);

function loadOtherScript() {
  var scriptTag = document.createElement('script'),
      head = document.getElementsByTagName('head');
  scriptTag.onload = function() { tt.doneLoading(); };
  scriptTag.setAttribute('type', 'text/javascript');
  scriptTag.setAttribute('src', script);
  head[0].insertBefore(scriptTag, head.firstChild);

if (document.attachEvent) {
} else {

The IE code uses document.write to insert a script tag with
a unique ID, then it watches for changes to the readyState
attribute. Confused? Well, it's not too difficult to follow this code,
but it would be nicer if we didn't need it.

Here's the proof it works!

If you're interested in this area, RequireJS is
shaping up to be a good library.


The single unit tests can now actually run in IE, even IE6. There's
still a lot left to do to get full cross-browser support into Turing,
but getting the tests going is an important first step.

To get this update, make sure you run git submodule update
to get the latest version of the Turing