- From: João Eiras <joaoe@opera.com>
- Date: Wed, 23 Nov 2011 18:18:24 +0100
- To: public-webapps@w3.org
> The problem, as Aryeh said, is that *almost all* of XPath can already > be done easily done with a combination of Selectors and JS (and adding > findAll and NodeArray will make the two combine together much more > neatly). We can pull functionality that's still missing into either > Selectors or JS, but there's not too much. For example, XPath's > axises seem pretty useful, and it would be very easy to expose that > functionality from JS, to quickly retrieve all the elements on a > particular axis. Adding a few small extensions to the existing two > technologies is better then adding a third technology. > It's not a third technology. XPath exists already and is widely supported. The third technology is actually the extensions you want for Selectors and DOM, while being a repetition of effort because those features are already supported in XPath, and those man hours would be better spent doing something worthwhile. What would be hard to specify ? All the new traveral APIs and the new Selector additions, or just provide an API similar to the Selectors API for XPath ? Anyway, I'm all fine for having new Selector features and new DOM APIs, and I wish you good luck with that. I'm just not fine with people hindering the possibility to make a 1st class API for XPath.
Received on Wednesday, 23 November 2011 17:19:02 UTC