Re: XPath and find/findAll methods

On Wed, 23 Nov 2011 16:13:42 +0100, Aryeh Gregor <ayg@aryeh.name> wrote:

> 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.

You're making a choice for the developers. If developers want to use  
xpath, they should, it's their choice. Actually, they can, but the current  
DOM 3 XPath API is extremely convoluted..

The whole thing about patronizing developers about having to learn another  
technology is also not valid, besides being easily confused with  
intellectual arrogance. It's their choice again, and XPath is fairly  
simple.

XPath is already perfectly defined, supported, and implemented in many  
user agents. It's not just a bunch of wild ideas on how to make Selectors  
work with parents (which will never be accepted by the css working group),  
or support nested Selectors. If someone actually defined a second dialect  
for selectors, one for CSS and the other for the DOM API, then lots of  
effort would be wasted reinventing another selection syntax, still more  
limited than XPath.

Claiming that using Selectors plus DOM traversal is a solution is like  
saying iframes are a good alternative to XHR. Any use of DOM traversal is  
verbose and will be preferably avoided, and causes temporary objects to be  
created just to be gc'ed afterwards. But because Selectors don't do many  
useful things XPath does, the developer will either be frustrated, having  
to workaround the limitations of the API, use a selection library that has  
the features need, or wrap the current XPath API.

Lastly, the only thing that is needed is a specification perhaps the size  
(or even smaller) than the Selectors API specification to define an API  
that interprets XPath. There's no need for extra syntax sugar, nor to  
specify algorithms.

Received on Wednesday, 23 November 2011 16:32:32 UTC