Children of The DOM

Close node relationships in the DOM have always been problematic, because most interpretations of the DOM include whitespace text-nodes, which scripts don’t usually care about.

It’s right that they should be included, of course, because it’s not up to implementations to decide whether this or that node is important. Nevertheless, whitespace text-nodes are usually not important, they just get in the way, complicating what should be simple relationships like firstChild and nextSibling.

Here’s a simple markup example to demonstrate:

<ul>
  <li>list-item 1</li>
  <li>list-item 2</li>
  <li>list-item 3</li>
</ul>

So the firstChild of that <ul> element is not the first <li> element, it’s the whitespace (i.e. the line-break and tab) between the <ul> and <li> tags. Likewise, the nextSibling of that first list-item is not the second list-item, it’s the whitespace text-node in-between.

The Classic Solution

This is nothing new, and traditionally we’ve had three basic ways of dealing with it. The first is to use a collection-based reference like this:

var item = list.getElementsByTagName('li')[0];

The second approach is to iterate past the unwanted nodes, using a nodeType test to determine when we have the node we want:

var item = list.firstChild;
while(item.nodeType != 1)
{
  item = item.nextSibling;
}

The third and most brute-force solution is simply to remove the unwanted nodes altogether, using a recursive function like this (which also removes comment nodes):

function clean(element)
{
  for(var x = 0; x < element.childNodes.length; x ++)
  {
    var child = element.childNodes[x];
    if(child.nodeType == 8 
      || (child.nodeType == 3 && !/S/.test(child.nodeValue)))
    {
      element.removeChild(element.childNodes[x --]);
    }
    if(child.nodeType == 1)
    {
      clean(child);
    }
  }
}

The Element Traversal Solution

These solutions all work, but there is a much simpler and eaiser way of getting the elements references we want, using a suprisingly little-known set of references defined in DOM3 Element Traversal.

The Element Traversal specification defines four new references, which only relate to element nodes, effectively ignoring all other types:

• firstElementChild
• lastElementChild
• nextElementSibling
• previousElementSibling

So now we can get those list-item references in a much more straightforward way, and it doesn’t matter how many whitespace text-nodes (or anything else) are in-between:

var item = list.firstElementChild;
var item2 = item.nextElementSibling;

The specification also defines a childElementCount property, which is equivalent to childNodes.length when all non-element nodes are disregarded.

The Real-World Solution?

So can we rely on these properties, will they work in the browsers we code for? The answer is “yes” for the most part. Older versions of IE are the usual story, but for IE9 or later, or any reasonably-recent version of any other major browser, we find that all these properties are supported, and have been for quite a while.

PPK’s DOM Compatibility tables give us the low-down, and show that we don’t need to worry at all about lack of browser support — unless we have to support IE8.

So I guess it’s one of those things, just like selector queries used to be — if older browsers are an issue, then libraries can provide the fallback, or you can continue to use the traditional solutions we’ve always relied on. But if you’re lucky enough not to have to think about those older browsers, then the Element Traversal properties will certainly make life easier.

I could also point out that earlier versions of IE have a different view of the DOM — unlike all other browsers, they don’t include whitespace text-nodes. So at a pinch, you could always do something like this:

function firstChild(element)
{
  //using pre-defined browser variable
  if(isie)
  {
    return element.firstChild;
  }
  return element.firstElementChild;
}

A browser test is appropriate for that, rather than simply testing whether firstElementChild is defined, because lack of support for that property doesn’t necessarily indicate an implementation where whitespace isn’t included. The difference is unique to IE, so it’s IE we’d have to test for.

The Common-Sense DOM

To me, these Element Traversal properties are something a breeze of common-sense in W3C specifications — ratifying in standards the practical view that most of have of the DOM. They’re certainly a lot more approachable than DOM2 Traversal ever was (anyone here using TreeWalker? No, I didn’t think so!). The underlying problem that DOM Traversal tried to solve, is that implementations can’t know which types of node a script will care about, yet it tried to solve this problem by continuing to treat all types of node as equal.

But all nodes are not equal — it’s elements that count — and the Element Traversal specification puts them center-stage.