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

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 12:05 PM, Bjoern Hoehrmann <derhoermi@gmx.net>wrote:

> * 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")
>

Most people would accomplish that using jQuery. Something like:

var previous = $(current).closest("tr").prev()

I'm not exactly sure what `current` is in this case. What edge-cases are
you worried about when you say that the JavaScript is "quite involved"?


>
> 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
> >people."
> >
> >"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
> >meaningless.
>
> No.
> --
> 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/
>
>