W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: XPath and Selectors are identical, and shouldn't be co-developed

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 30 Nov 2011 21:05:57 +0100
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <n9vcd7p8s3fvor6dvj774q3plqc2aj8bo1@hive.bjoern.hoehrmann.de>
* Tab Atkins Jr. wrote:
>Disclaimer: I'm a CSSWG member, was previously a web developer by
>trade (now am a webkit engineer/spec author), and was only vaguely
>aware of XPath a week ago.

XPath support has been available in web browsers for over decade. If you
have so far been unaware of it, that likely means you rarely if ever run
into problems where XPath offers a good solution, and have basically no
insight into the community that does. I on the other hand regularily run
into such problems.

Just this weekend I wrote an MP3 player. It hosts a web browser for the
user interface to make it easy to adjust it for people who are familiar
with technologies implemented by web browsers. One feature it has is na-
vigation through the playlist using arrow keys. You have a track that is
currently selected, "up" should go to the previous track, "down" to the
next one, in playlist order.

While there were various initiatives to standardize focus navigation in
2006 if I recall correctly, they have not quite materialized yet, so it
takes scripting to implement this. Tracks in the playlist are table rows
and so pressing "up" should move the cursor to the single node that is
the previous table row from the perspective of the current one. That is

  var previous = current.selectSingleNode("previous::tr")

as it has been available in Internet Explorer for over a decade. There
is no Selectors equivalent and the JavaScript code for this is rather
involved. There is also no proposal for Selectors extensions, or Java-
script or DOM or whatever extensions to make this considerably easier. 
Yes, those could be implemented, that argument is from the 1990s and it
does not really result in actual implementations.

Also note in particular that you can read the code above even without
knowing anything about XPath and yet you will fully understand from the
context it is used in what it does. It is how code should be written.

>In the recent discussions about XPath, I keep hearing a particular
>theme that I believe is untrue, namely that XPath and Selectors
>address different use-cases.  For example, Liam recently sent an email
>containing the following:
>"XPath selectors give a different way of looking at finding things than
>CSS selectors and probably appeal in differing amounts to different
>"XPath has different goals from CSS selectors, and there's not actually a
>battle between them."
>Neither of these are true.  The second could have been defended as
>true several years ago, but not today.  I will defend my statement,
>and then make the further argument that, due to the two being
>identical, it is a bad idea to develop both of them.

If you are actually interested in discussing why some people have some
need for good XPath support, then it would be helpful if you could cut
down on the rhetoric. If you make this about what is "true", then you
are likely to create dynamics in the discussion that are unhelpful, in-
cluding that people assume you care mostly about revealing The Truth,
and don't actually care about views that differ from your own.

I note that I find the first quote quite accurate and important, but I
doubt you can actually appreciate how turning your thoughts into XPath
syntax is different from turning them into Selectors syntax with no ex-
perience in actually using XPath, in addition to you being a man on a
mission. Add that you have chosen to express yourself in a manner that
actively discourages discourse, I won't bother to try.

>Both Selectors and XPath take some arbitrary notion of "nodes" with
>certain aspects and a tree structure and, starting from the set of all
>relevant nodes, repeatedly filter and transform the set until arriving
>at a result.  They both do this in effectively identical ways; this
>isn't like some concept of "turing equivalence" which can easily be

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, 30 November 2011 20:06:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:46 UTC