Re: XPath and find/findAll methods

On Wed, Nov 23, 2011 at 9:18 AM, João Eiras <joaoe@opera.com> wrote:
>> The problem, as Aryeh said, is that *almost all* of XPath can already
>> be done easily done with a combination of Selectors and JS (and adding
>> findAll and NodeArray will make the two combine together much more
>> neatly).  We can pull functionality that's still missing into either
>> Selectors or JS, but there's not too much.  For example, XPath's
>> axises seem pretty useful, and it would be very easy to expose that
>> functionality from JS, to quickly retrieve all the elements on a
>> particular axis.  Adding a few small extensions to the existing two
>> technologies is better then adding a third technology.
>
> It's not a third technology. XPath exists already and is widely supported.
>
> The third technology is actually the extensions you want for Selectors and
> DOM, while being a repetition of effort because those features are already
> supported in XPath, and those man hours would be better spent doing
> something worthwhile.

Yes, XPath exists.  It's still a third tech, since it's different from
both Selectors and JS.  ^_^  When I talked about "adding" it, I was
referring to making it a recognized and supported part of the
platform, rather than one of the random legacy features that browsers
have lying around everywhere.  Right now, authors in general have zero
awareness of XPath, so recognizing it would be effectively "adding"
it.


> What would be hard to specify ? All the new traveral APIs and the new
> Selector additions, or just provide an API similar to the Selectors API for
> XPath ?

I care little for how hard this is to specify.  My arguments against
XPath are all about the complexity of the platform for authors, not
the complexity of the specification.


> Anyway, I'm all fine for having new Selector features and new DOM APIs, and
> I wish you good luck with that. I'm just not fine with people hindering the
> possibility to make a 1st class API for XPath.

Unfortunately, I believe that hindering it is a good move for the
platform.  However, I've been reading through XPath this morning, and
found that (a) it's remarkably more similar to Selectors than I
thought in functionality, and (b) it would be much easier than I
thought to pull in some of XPath's ideas that don't yet exist in JS or
Selectors.

For example, I didn't realize at first that XPath's axises are the
*exact* same thing as Selectors' combinators.  The 'child',
'descendant', and 'following-sibling' axises are identical to existing
combinators in Selectors.  XPath's 'descendant-or-self' axis (which I
know is useful from jQuery experience) and 'following' axis (which is
a convenient combo of 'following-sibling' and 'descendant-or-self')
seem useful and could be added to Selectors as new combinators.  XPath
also has reversed versions of every axis, which Selectors is
approaching in a different way with the subject indicator and, in the
future, the use of :matches() with complex selectors.  The
'attributes' and 'namespace' axises are already mostly covered with
attribute and namespace selectors in Selectors, and the remaining
functionality can be done trivially with JS and the filter function on
NodeArray.

Of the predicates, several exist in Selectors already, while the
remaining are all trivial to do with JS and the filter function on
NodeArray.  Further, there has been discussions of providing a way to
create author-defined pseudoclasses backed by JS functions (probably
just for batch-process Selectors like the find() function, not
Selectors in CSS), which would enable all of them to be emulated in
Selectors by a small and easy-to-write library.

So, in conclusion, there appears to be *very little* we would actually
need to pull from XPath to make the existing technologies match it in
features and convenience.

~TJ

Received on Wednesday, 23 November 2011 18:24:15 UTC