A little while ago a nightly of Firefox 3.1 included support for the new Element Traversal API proposed by the W3C.

The purpose of this proposal is to make it easier for developers to traverse through DOM elements without having to worry about intermediary text nodes, comment nodes, etc. This has long been a bane of web developers, in particular, with cases like document.documentElement.firstChild yielding different results depending on the whitespace structure of a document.

The Element Traversal API introduces a number of new DOM node properties which can make this traversing much simpler.

Here’s a full break-down of the existing DOM node properties and their new counterparts:

These properties provide a fairly simple addition to the DOM specification (and, honestly, they’re something that should’ve been in the specification to begin with).

There is one property that is conspicuously absent, though: .childElements (as a counterpart to .childNodes). This property (which contained a live NodeSet of the child elements of the DOM element) was in previous iterations of the specification but it seems to have gone on the cutting room floor at some point in the interim.

But all is not lost. Right now Internet Explorer, Opera, and Safari all support a .children property which provides a super-set of the functionality that was supposed to have been make possible by .childElements. When support for the Element Traversal API was finally landed for Firefox 3.1, support for .children was included. This now means that every major browser will support this property (far in advance of all browsers supporting the rest of the true Element Traversal specification).

I think that the Element Traversal spec is missing a huge opportunity here to specify something that has become a de facto standard amongst browsers. Maybe it’ll make the second version of the Element Traversal spec, heh.

There are two big points that need to be explored here:

1. Now that the .children property is virtually everywhere how can we start to use it to simplify our code?
2. Can we use .children, or parts of the Element Traversal API, to help speed up existing code?

To answer this question I mocked up a quick little plugin for jQuery that replaces the internals of the existing .prev(), .next(), .prevAll(), .nextAll(), .siblings(), and .children() methods with .children and the Element Traversal API methods.

The resulting code is absolutely simpler – previously there were numerous checks to see if a Node was, or was not, a DOM element – which resulted in lots of extra kludgy methods to handle those cases. But was the code faster?

I plugged the code into Dromaeo to see if there was any speed up in Firefox 3.1. The result? There is no discernible speed improvement to using the new DOM Traversal methods (.firstChildElement, etc.). This isn’t, necessarily, a bad thing – we just got the same performance that we see now but with a better API.

However there is a large improvement in speed when using .children (for the .siblings() and .children() jQuery methods). With this addition .siblings() is 84% faster and .children() is 35% faster. Considering that the .children method is now available in all browsers it’s making a lot of sense for people to get on board and start using it in their code bases for a definite hot path to extra performance. (Although, this is definitely not a new revelation – with frameworks like Dojo having used .children in their selector code for quite some time now.)

If nothing else the argument to having a simple branch in your code to handle using .children is absolutely becoming more compelling.