On Wed, 23 Nov 2011 16:13:42 +0100, Aryeh Gregor <[email protected]> wrote:
On Tue, Nov 22, 2011 at 7:08 PM, Jonas Sicking <[email protected]> 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.
