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

Re: XPath and find/findAll methods

From: Aryeh Gregor <ayg@aryeh.name>
Date: Wed, 23 Nov 2011 10:13:42 -0500
Message-ID: <CAKA+Axm1GrC6SsaLh7k8j6vb7XmLWdRFcd094w3hEGiZP7mO+w@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
On Tue, Nov 22, 2011 at 7:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

This is the key thing.  We're talking about JS APIs, so you can
already walk the DOM and do anything you want.  Or you can use
selectors and get a limited set of effects much more concisely and
efficiently.  There is no need for yet a third language that's at an
intermediate level of expressiveness and conciseness.  In the cases
that selectors can't fully handle, use selectors plus extra JS logic.
This means knowing only two languages instead of three, and those two
languages are ones authors have to know anyway.  Authors would just
have no reason to learn XPath even if it were easier to use, because
the value is adds is too limited.
Received on Wednesday, 23 November 2011 15:14:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC