- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 22 Nov 2011 14:20:29 +0100
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: "\"Martin Kadlec\" (BS-Harou)" <bs-harou@myopera.com>, public-webapps@w3.org
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 UTC