Re: XPath and find/findAll methods

On Tue, Nov 22, 2011 at 4:16 AM, James Graham <jgraham@opera.com> wrote:
> Right, one of the issues with XPath is that the DOM3 XPath API is without
> doubt the worst API on the web platform. With a sane API there might be more
> demand for XPath since it can be used for things that the CSSWG are unlikely
> to ever allow in selectors for performance reasons. As Simon points out,
> there is even a preexisting API that does more or less the right thing and
> is implemented in IE and Opera.

I believe there's a decent chance that we'll sprout a "batch
processers" selectors spec or profile of the existing spec to handle
things that are too expensive for normal CSS but perfectly fine when
run in JS.


On Tue, Nov 22, 2011 at 4:31 AM, Martin Kadlec <bs-harou@myopera.com> wrote:
> 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)]";

This can be done easily using functionality in the new Selectors 4 draft:

article > div:nth-child(2) input:matches([type=text], :not([type]),
[type=color])


> 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]";

(a) can't be done in current CSS, largely for performance reasons,
though as I say above to James, there's a good chance we'll sprout a
profile of the Selectors spec that allows some things that are fine in
JS but not in CSS.

(b) can be done with :nth-child(29 - n) if you're on the child or
sibling axises.  The functionality of using position() on the other
axises can't be matched directly with Selectors, but if you're doing
JS it's trivial to do a slice to get the ones you want.

(c) is not doable, because Selectors only deals with elements, which
*have* attributes.  Again, though, one can trivially get at the with
javascript once you've selected the elements.

(d) can be done with the new subject indicator in the Selectors 4
draft:   a! > div  (syntax pending, but that's the general idea)


> 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.
>
> There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other.

They solve the same set of use-cases in the same way, with the only
difference being relatively minor abilities of each.  That definitely
makes them rivals.  ^_^  We don't need two selection mechanisms with
substantially different syntaxes.  XPath may be useful as a source of
more ideas to pull into Selectors, but that's it.

~TJ

Received on Tuesday, 22 November 2011 16:07:31 UTC