- 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
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 UTC