Re: XPath and find/findAll methods

On Tue, Nov 22, 2011 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> I really don't think that selectors can ever compete with the
> expressiveness of XPath. Consider the following expression:
>
> //div[count(.//span) > 6][count(.//span[@data-foo = ../@data-bar]) mod 2 = 1]
>
> This expression finds all <div> elements which has at least 6 <span>
> descendants and where an odd number of those <span> elements have a
> "data-foo" attribute equal to its parents "data-bar" attribute. It is
> obviously trivial to add arbitrary additional complexity to this
> expression.
>
> Trying to do the same thing in Selectors will just result in a
> incomprehensible mess.
>
> At the same time, XPath can't ever compete in expressiveness to
> Javascript. Finding all <div> elements with a "data-foo" attribute
> that contains a prime number is not possible in XPath but trivial in
> javascript.
>
> I'm not convinced that it's worth investing in XPath. At least not
> beyond the low-hanging fruit of making most of the arguments to
> .evaluate optional. But I think trying to make selectors compete in
> expressiveness with XPath is a loosing battle.

I agree with everything you say.  I believe there are still things
that XPath can do that we can pull into Selectors, but we definitely
don't want the whole thing.  XPath's notion of axis switching allows
for a lot more power in a consistent notation than what you can get
with Selectors.

This is why I support .find() and NodeArray (or whatever it gets
called), because they make it *really easy* to mix together Selectors
and JS for essentially the same effects.  Rather than having to add

document.querySelectorAll("A :something-super-complex() B")

we can just do

document.findAll("A").filter(complex-function).findAll("B")

~TJ

Received on Wednesday, 23 November 2011 00:20:40 UTC