I spent some time playing with the XPath support in WebKit a few days ago, and I’ve come to the conclusion that it’s not quite ready for prime time. I know the software is still beta (thankfully). I found no problems with simple XPath evaluations, but things get screwy when you start to factor in namespaces. All the problems I found stem from one flaw: you cannot assign a custom namespace resolver.

One of the parameters in the XPathEvaluator.evaluate() method is a namespace resolver. The W3C documentation allows two types of values for this parameter. The first being an object implementing the XPathNSResolver interface, and the second is a user-defined function that returns a string and accepts a string as a parameter.

In the latest nightly build, only an XPathNSResolver object can be passed to the evaluate() method, or else a NAMESPACE_ERR error is thrown. Also, it appears that you cannot override the lookupNamespaceURI() method, the only member in the XPathNSResolver class. Doing so also ends in a NAMESPACE_ERR error.

So what exactly does this mean? It means that WebKit is incompatible with the other browsers when it comes to namespaces, and incorporating it into code that supports IE, Firefox, and Opera requires yet another code branch. It also means you cannot consolidate all the different browser interfaces into one, as selecting nodes in WebKit currently requires different rules than the other browsers.

A bug has been submitted (not by me), and I'm currently writing a test case for it.

All in all, I'm glad I can start to work on some of my scripts and use XPath, but for those that require namespaces (the new XParser comes to mind. No it's not released yet.), it'll be a while before they're stamped with "Works in Safari/WebKit".