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:20:41 -0800
Message-ID: <CAMFeDTXMMvJZ5=Se-ZS1MAm2zAdAE2HVyWGEJvGzpf0J-rMLGA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, 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:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Nov 22, 2011 at 11:52 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > On Tue, Nov 22, 2011 at 11:38 AM, Robin Berjon <robin@berjon.com> wrote:
> >> On Nov 22, 2011, at 18:31 , Boris Zbarsky wrote:
> >>> On 11/22/11 12:29 PM, Robin Berjon wrote:
> >>>>>> d - "//div[parent::*//a]";
> >>>>>
> >>>>> (d) can be done with the new subject indicator in the Selectors 4
> >>>>> draft:   a!>  div  (syntax pending, but that's the general idea)
> >>>>
> >>>> I think that the example you show selects the<a>  parent of a<div>,
> not<div>s that have parents containing an<a>.
> >>>
> >>> Yes, that's what Tab's selector selects too.  The '!' after the 'a' is
> important there.
> >>
> >> Wait, I thought I'd grasped the gist of S4 but now you're confusing me
> :) My reading of Tab's selector is that it
> >> matches the <a> in <a><div/></a>. What Martin's XPath matches is the
> <div> in <section><div/><p><a/></p></section> (amongst many other
> variants). It's "all div's whose parents have an a descendent".
> >
> > Pretty sure that Boris misunderstood your comment.  I did too, at
> > first, since I wasn't sure which example you were referring to.  ^_^
> >
> > You are correct on both counts.  "a! > div" matches <a> elements with
> > a <div> child.  To match the XPath selector, you need something more
> > like "*:matches(:scope a) > div", which isn't yet a valid selector,
> > but is roughly in line with how we want to extend :matches() in the
> > future.
>
> 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]
>

The flip side of this is representing certain common HTML idioms in XPath
(like "find me an element with the class 'foo'" or even "find me an element
with the class 'foo' that is an already-visited link").


>
> 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.
>
> / Jonas
>
>
Received on Wednesday, 23 November 2011 00:21:30 GMT

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