- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Tue, 22 Nov 2011 14:05:41 +0100
- 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 UTC