Getting More Detailed with Compounds

So far, we haven’t dealt with any compound location paths…each of our expressions has just gotten nodes that are direct children of the context node. However, we can continue to move up and down the document tree by combining single location paths. One of the ways we can do this (and this should look quite familiar to anyone who has moved through directories elsewhere) is by using the forward slash ‘/’. The forward slash continues to move us one step down in the tree, relative to the preceding step.

For example, consider the following:

The expression above will first go to the root node thanks to our ‘//’. It will then get any div elements that are descendants of the root node. Then, we use the forward slash to move down one more level. Now we are saying to get all h3 elements that are direct descendants of one of the div elements that was returned. Finally, we once again use our forward slash to move down one more level, and tell the expression to return any span elements that are direct descendants of the h3 elements we already found.

In addition, we can use the double period ‘..’ to select an elements parent nodes. For example, if we use an expression like ‘//@title’, we will get all title attributes in the document. Let’s say that what we actually wanted, is all elements in the document that have title attributes. Using the parent selector (..), we can do just that. The expression ‘//@title/..’ first grabs all title attributes. Then the double period tells the expression to step back up and grab the parent node for each of those title attributes.

This is a pretty handy little feature. We can use the double period to select sibling elements by doing something like ‘//child/../sibling’ where child is the child element, and sibling is the sibling element we are looking for. For example, ‘//h3/../p’ would get all p elements that are siblings of h3 elements.

Finally, we can use a single period ‘.’ to select the current node. You will see this become useful when we introduce the use of predicates.

Speak Of the Devil

Each expression we’ve seen returns a bunch of nodes matching criteria. Occasionally, we will want to refine this even further. We can do that using predicates, which are simply Boolean expressions that get tested for each node in our list. If the expression is false, the node is not returned in our results; if the expression is true, the node is returned.

Predicates use the typical Boolean operators, ‘+’, ‘<’, ‘>’, ‘<=’, ‘>=’, ‘!=’, ‘and’ and ‘or’. As promised, the single period becomes much more useful when combined with predicates. For example, we can grab all h3 elements that have a value of “Yaddle” by using the following expression:

The dot tells the expression to check for the value of that current node. If the value equals “Yaddle”, the h3 will be returned to us. Let’s take a look at another example, one maybe a bit more practical. Let’s say you have a calendar of events, and all you want to retrieve all the events that occurred between 2005 and 2007. Being the smart developers we are, we wrapped all the event years in a span with a class of year, like so:

Getting all the year spans where the value is between 2005 and 2007 is easy. We can simply do this:

Ok…granted, at first glance that is pretty ugly, so let’s break it down.

1. //span – Get all span elements
2. [@class="year"] – Make sure the only span elements we grab have a class of ‘year’
3. [.>=2005 and .<=2007] – Make sure the value of span is between 2005 and 2007. We use the ‘<=’ and ‘>=’ operators versus the ‘<’ and ‘>’ operators because we want to also return values in the years 2005 and 2007.

Making sense out of all the slashes and brackets can take some getting used to, so don’t be discouraged if it takes you awhile before you can make sense out of what is happening there. Once you get more familiar with the syntax used, you will find you can create some really robust checks in one line of code that would have taken numerous iterations using DOM methods.

This is going to be a multi-post series, as there is just so much you can accomplish by using XPath expressions that if I tried putting it into one post, no one would have the time to sit and read the whole thing.

What is XPath?

Any of you out there who are familiar with XSLT will no doubt be familiar with the XPath language. For the rest of you, XPATH is used to identify different parts of XML documents by indicating nodes by position, relative position, type, content, etc.

Similar to the DOM, XPath allows us to pick nodes and sets of nodes out of our XML tree. As far as the language is concerned, there are seven different node types XPath has access to (for most Javascript purposes the first four node types will most likely be sufficient):

1. Root Node
2. Element Nodes
3. Text Nodes
4. Attribute Nodes
5. Comment Nodes
6. Processing Instruction Nodes
7. Namespace Nodes

How Does XPath Traverse the Tree?

XPath can use location paths, attribute location steps, and compound location paths to very quickly and efficiently retrieve nodes from our document. You can use simple location paths to quickly retrieve nodes you want to work with. There are two basic simple location paths – the root location path (/) and child element location paths.

The forward slash (/) servers as the root location path…it selects the root node of the document. It is important to realize this is not going to retrieve the root element, but the entire document itself. The root location path is an absolute location path…no matter what the context node is, the root location path will always refer to the root node.

Child element location steps are simply using a single element name. For example, the XPath p refers to all p children of our context node.

One of the really handy things with XPath is we have quick access to all attributes as well by using the at sign ‘@’ followed by the attribute name we want to retrieve. So we can quickly retrieve all title attributes by using @title.

Using XPath in Javascript

That’s all well and fine, but how do we use this in Javascript? Right now, Opera, Firefox and Safari 3 all support the XPath specification (at least to some extent) and allow us to use the document.evaluate() method. Unfortunately at this time, IE offers no support for XPath expressions. (Let’s hope that changes in IE8)

The document.evaluate method looks like this:



The expression argument is simply a string containing the XPath expression we want evaluated. The contextNode is the node we want the expression evaluated against. The namespaceResolver can safely be set to null in most HTML applications. The resultType is a constant telling what type of result to return. Again, for most purposes, we can just use the XPathResult.ANY_TYPE constant which will return whatever the most natural result would be. Finally, the result argument is where we could pass in an existing XPathResult to use to store the results in. If we don’t have an XPathResult to pass in, we just set this value to null and a new XPathResult will be created.

Ok…all that talk and still no code. Let’s remedy that shall we. Here’s a very simple XPath expression that will return all elements in our document with a title attribute.



If you take a look at the XPath expression we passed in “//*[@title]“, you will notice that we used the attribute location step followed by the attribute we want to find, ‘title’. The two forward slashes preceding the at sign is how we tell the browser to select from all descendants of the root node (the document). The asterisk sign says to grab any nodes regardless of the type. Then we use the square brackets in combination with our attribute selector to limit our results only to nodes with a title attribute.

The evaluate method in this case returns an UNORDERED_NODE_ITERATOR_TYPE, which we can now move through by using the iterateNext() method like so:



Since each item in the results is a node, we need to reference the text inside of it by using the textContent property (line 3). You can only iterate to a node once, so if you want to use your results later, you could save each node off into an array with something like below:



Now arrTitles is filled with your results and you can use them however often you wish.

This is just the beginning…as we continue to look at XPath expressions and introduce predicates and XPath functions, you will start to see just how truly robust XPath expressions are. At this point, IE doesn’t support using XPath expressions in Javascript, but with each of the other major browsers having some support, and major Javascript Libraries placing an emphasis on using them, it’s only a matter of time before we can begin using these expressions to create more efficient code.