W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: XPath and find/findAll methods

From: Yehuda Katz <wycats@gmail.com>
Date: Tue, 22 Nov 2011 16:28:32 -0800
Message-ID: <CAMFeDTWeiOnYtpm=9o_u+RK0e=x57OEbxxsogg022Fj2O8qFDw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Robin Berjon <robin@berjon.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
Yehuda Katz
(ph) 718.877.1325


On Tue, Nov 22, 2011 at 4:19 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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")
>

This is essentially the same API we have in jQuery. I can confirm that
allowing selectors to be mixed in with JavaScript traversal and filtering,
possibly via additional selectors, does in fact alleviate the need for
additional selectors. I can't think of the last time someone asked jQuery
for new custom selectors, and we *do* have the infrastructure for it.


>
> ~TJ
>
>
Received on Wednesday, 23 November 2011 00:29:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT