W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: XPath and find/findAll methods

From: James Graham <jgraham@opera.com>
Date: Wed, 23 Nov 2011 09:59:33 +0100 (CET)
To: Jonas Sicking <jonas@sicking.cc>
cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Robin Berjon <robin@berjon.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
Message-ID: <alpine.DEB.2.00.1111230945470.22524@sirius>
On Tue, 22 Nov 2011, Jonas Sicking wrote:

> I'm not convinced that it's worth investing in XPath. At least not
> beyond the low-hanging fruit of making most of the arguments to
> .evaluate optional. But I think trying to make selectors compete in
> expressiveness with XPath is a loosing battle.

Right, I think people agree on the general facts that XPath is more 
expresive than selectors at the cost of being more complex for simple 
cases and less familiar to "typical" authors. I presume everyone also 
agrees that DOM3 XPath is so awful as to be virtually unusable. The only 
remaining question is whether the cost of making the XPath API more 
palatable is worth it given the strength of the use cases and the fact 
that one can always solve any use case by resorting to manually walking 
the DOM.

My feeling is that the specific approach we should consider is "adopt the 
selectNodes and selectSingleNode APIs that Opera implements". Of course 
that is rather easy for me to suggest because it doesn't require me to do 
any work :) On the other hand, other vendors get to suggest standardising 
their already implemented APIs way more often, so I don't feel that bad :) 
Since these APIs are just wrappers around existing functionality it seems 
like they should be quite trivial to implement (much easier than adding 
new features to selectors, for example).
Received on Wednesday, 23 November 2011 09:00:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT