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

Re: XPath and find/findAll methods

From: Robin Berjon <robin@berjon.com>
Date: Tue, 22 Nov 2011 14:20:29 +0100
Cc: "\"Martin Kadlec\" (BS-Harou)" <bs-harou@myopera.com>, public-webapps@w3.org
Message-Id: <28DD6356-63A3-4FA1-9A91-5CB6197D3115@berjon.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
On Nov 22, 2011, at 14:05 , Lachlan Hunt wrote:
> On 2011-11-22 13:31, Martin Kadlec (BS-Harou) wrote:
>> 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?

I think that everyone would be pretty much happy if Selectors added all that's missing in XPath  in other words, no one cares much about syntax. Traditionally though, this has been rejected for (IMHO genuine) performance reasons). ISTR someone talking of the possibility of having Selectors, and then a subset that would be Selectors for CSS but at that point you have to wonder why not just use what we already have? Also, I think it would create a fair bit of confusion.

A classic UC that Martin missed above is //text().

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

A typical example is generating the current section + subsection number, which works nicely with a combination of count(), ancestor::, and preceding::.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 22 November 2011 13:20:58 GMT

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