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

Re: XPath and find/findAll methods

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Tue, 22 Nov 2011 14:05:41 +0100
Message-ID: <4ECB9E25.4030405@lachy.id.au>
To: "\"Martin Kadlec\" (BS-Harou)" <bs-harou@myopera.com>
CC: Robin Berjon <robin@berjon.com>, public-webapps@w3.org
On 2011-11-22 13:31, Martin Kadlec (BS-Harou) wrote:
> In my opinion, there are two use cases for XPath:
> 1) It's much harder to write the CSS selector
> e.g.:
> CSS: "article>  div:nth-child(2) input[type=text], article>  div:nth-child(2) input:not([type]), article>  div:nth-child(2) input[type=color]";
> XPath: "//article/div[2]//input[@type='text' | @type='color'| not(@type)]";

There was a proposal to handle this.

input:-moz-any([type=text], [type=color], :not([type]))

The current draft of Selectors 4 includes :matches(), though, which can 
partially handle that case, excluding :not([type]), which would have to 
be left separate.

input:matches([type=text], [type=color]), input:not([type])

> 2) It's impossible to write the CSS selector (or really really hard/long)
> a - "*[@data-price>30]";
> b - "*[position()<30]";
> c - "div[@*]";
> d - "//div[parent::*//a]";

Are such features really useful and desired by authors, and if so, is it 
possible that they could instead be introduced as features in Selectors?

> Anyway, mostly when I use XPath instead of CSS selectors it's
> because  of XPath axis - the ability to go not just deeper but also higher in the
> element tree. XPath can also work with any node, not just elements.

Could you describe a clear use case where this is useful for your needs?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Tuesday, 22 November 2011 13:06:17 GMT

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