Re: XPath and find/findAll methods

On Wed, Nov 23, 2011 at 8:31 AM, João Eiras <joaoe@opera.com> wrote:
> 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.

Yes, we make choices for developers all the time.  That's called
"being a responsible spec author".  Keeping the platform
simultaneously as simple and as powerful as possible is challenging,
but it's our mandate.  Offering every possible functionality *sounds*
nice until you actually experience it; then it's called "bloat".


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

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.

~TJ

Received on Wednesday, 23 November 2011 17:02:33 UTC