Re: XPath and find/findAll methods

* Tab Atkins Jr. wrote:
>Come on, Robin, you're being unreasonable.  You and I both know
>there's a huge difference between "new features require small amounts
>of new syntax" and "oh look, it's an entirely different language".

I can't make heads or tails of the 'nth' syntax despite implementing it
a number of times, I always have to look up which direction '~' goes, I
can't imagine what `a!> div` or `:matches(:scope a) > div` might match,
and `:has(a) > div` requires a good bit of meditation. If I go to the
draft, it tells me that `:matches(:scope a) > div` isn't even valid.

When I learned XPath, I already knew "." from file paths, it stands for
the context you are in, ".." is for the context one level above, "/" is
the root, parent and child are separated by "/", and I knew from many
programming languages that "+" is addition, "|" is union, list[3] refers
an element in a list, "*" is a wildcard, [@price > 30] is a Where query.

It doesn't really matter that the languages are different, what matters
is how they differ, how they are constructed, what experience learners
may already have, what tools are available that could aid them, and so
on. The underlying argument that `:nth-last-of-type(+3n - 2)` is easier
because authors have used `#header` in the past is rather silly.

>Robin, you're familiar with XPath.  You look at it and go "Oh, neat,
>it has all the features I need!".  I'm not.  I look at it and go "Oh,
>look, somebody took a subset of Selectors, gave it a different syntax
>for some reason, and then added some new stuff.  I can't use the new
>Selectors stuff with the new XPath stuff, though, and now I have to
>remember two different syntaxes for the basic stuff.  I am a sad
>tab.".  I am quite certain that my position is closer to that of the
>average author than yours.

This is rather a matter of "I need to make this query but browsers I
care about don't all support making it with css selectors. I am glad
I can't use XPath either because that option would make me sad."

I don't think there is much interest in browsers adopting XPath 2.0,
it would be a slow and buggy mess that would take many years to sta-
bilize across browsers and platforms, as is usual for everything they
attempt to implement, but you are not going to beef up selectors so
they could somehow compete with the expressiveness of XPath without
making the syntax even worse than it already is; and I rather doubt it
would be a good idea to have "advanced" selectors only for scripting.

For authors it would be much better to standardize the .selectNodes
and .selectSingleNode methods and then find scripting means to combine
them, like being able to compute the difference between two node sets
with a simple call. Microsoft, with LINQ to XML, language additions to
C#, and the generic IEnumerable extension methods have made a rather
palatable DOM and JavaScript alternative in this spirit, with XPath
support of course, but you wouldn't need it so often there. In some
ways, selectors there can look more like JSSS...
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 23 November 2011 00:37:57 UTC