JavaScript – XPath vs DOM API Comparison

CSS is not designed to be used as a selector. It's purpose is to mark similar items in markup, so that they can be styled in the same way across the document. Because jQuery (et al) is also related to styling, and functionality is often attached to similar items in markup, CSS selectors have become commonplace in that arena.

If this doesn't explain it then imagine what an XPath Stylesheet sould look like. Perhaps something like this:

/html/body/div/table/tr/td[3]/div {
    background-color: #800;
}

Now, if you add a column to the table, or add a div into the structure, or maybe redefine the first div using HTML5's <article> tag, you're going to have to go and redefine your style's path.

Or, in reverse, imagine having to put a CSS tag on everything, just so that you can find it. What a PITA that would be.

Crockford has given an extensive presentation titled "An Inconvenient API: The Theory of the Dom" where he more or less explains his opinions on the DOM. It's longish (1h 18m), but as most Crockford's presentations it's quite enjoyable and educative.

Cross browsers inconsistencies seems to be his main concern, and I agree it's the single most annoying thing about the DOM. He identifies:

• Proprietary traps (browser and server traps),
• Rule breaking,
• Corporate warfare,
• Extreme time pressure

as the key issues behind the various inconsistencies, adding that presentation, session, or interactivity was never anticipated in the original vision of the web. Some examples of the inconsistencies include:

• document.all, a Microsoft only feature,
• the fact that name and id used to be interchangeable.
• the different functions on retrieving nodes:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

and continues with a few more examples, mostly targeting traversing the DOM, memory leaks, and event trickling and bubbling. There is a summary slide, titled "The Cracks of DOM" that summarizes:

• The DOM buglist includes all of the bugs in the browser.
• The DOM buglist includes all of the bugs in all supported browsers.
• No DOM completely implements the standards.
• Much of the DOM is not described in any standard.

In short, it's a messy, messy API. It might seem like nitpicking, but you have to keep in mind that when you are developing for the web, you rarely get to pick the browser your customers will use. Having to test everything in at least two versions of each of the major browsers gets old very soon. An API is supposed to be consistent and the DOM was a victim of the browser wars, but it's getting better. It's still not as platform neutral as the W3C (and I think all of us) would like it to be, but browser vendors seem quite more eager to co-operate than they were five or ten years ago.