Crisp's blog

HTML5 will bring us some really cool things, not only in terms of new markup features but also in terms of extended features for forms and a very handy DOM extension in the form of a native (and thus lightning fast) getElementsByClassName method.

Firefox 3 beta already has a native implementation of getElementsByClassName and it's a real kicker. Once javascript libraries start implementing this as a branch in their selector-functions (some already have) you will start to see dramatic performance improvements for certain DOM-queries.

Now there are 2 things that I would like to point out. One is actually a warning and the other one is something that I feel is an oversight in the specification.

First for the warning: most javascript libraries normally return a static array with elements from their DOM-query functions. This is fine and most of the times also the only way. However, the native getElementsByClassName method is supposed to return a 'live NodeList'. That is also mostly fine until you start to do some manipulation on elements from this NodeList that affect the list itself.

A quick example:

JavaScript:

1 2 3

var foo = document.getElementsByClassName('foo'); for (var i = 0; i < foo.length; i++) foo[i].parentNode.removeChild(foo[i]);

That will make you quickly wonder why not all elements having a className of 'foo' are removed in the end
That is also why in my implementation I convert the NodeList to a static array using Array.slice() so it matches the returntype of the alternative branches.

Now there is one thing that made me wonder: getElementsByClassName can be fed multiple classNames (space-seperated) in order to find elements that have all of those classnames, so:

JavaScript:

1	var foobar = document.getElementsByClassName('foo bar');

will find all elements that have both className 'foo' and 'bar' (in any order).

That's also nice, but what if I want to select all elements that have either className 'foo' or 'bar'? From a technical point of view it is easier to filter the outcome of getElementsByClassName('foo') on the existance of className 'bar' for each element than to actually do an intersect on getElementsByClassName('foo') and getElementsByClassName('bar').

In fact, JS1.6 already has an Array.filter() generic that can easily be used to accomodate the usecase of selecting elements that match all of several classnames, but a native intersect method does not exist. If getElementsByClassName was specified to be also applicable to NodeLists it would even be easier to accomodate the usecase of selecting elements that have all of several classnames because than you could just as well do:

JavaScript:

1 2	var foo_and_bar = document.getElementsByClassName('foo').getElementsByClassName('bar');

So did the WHATWG/HTML5 WG aim here for a 'quick win' choosing the most easy implementable solution and disregarding the other, just as valid, usecase where you want to select elements with either one of a list of classnames? I wonder...