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/
