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

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.

It's actually rather irrelevant for my point.  I'm claiming that the
two technologies are rivalrous, because they do the *exact same thing*
and can't be used together easily.  I also argue that supporting two
rivalrous techs in the platform is bad for authors.* Instead, it's
healthier for the platform if we choose only one of them to work on.

XPath is either better than Selectors, roughly the same, or worse (or
it's incomparable, which I don't think can be argued).  If it's the
former, we should develop XPath *only*, and stop working on Selectors
in JS APIs.  If it's the latter, we should develop Selectors *only*,
and stop working on XPath in JS APIs.  If it's the middle, we should
choose one or the other based on other factors and work on it only
(and possibly merge some functionality).  I argue that it's roughly
the same.  It does some things better than Selectors, but Selectors
does some things better than XPath.  I also argue that using
JS+Selectors is easier than using JS+XPath, because the missing
functionality in Selectors is simpler and maps better to easy JS
operations.  This, combined with the fact that Selectors is very
obviously popular and more well-known than XPath, suggests that we
should be favoring Selectors.

* If two rivalrous techs are relatively new or have little usage, it
can make sense to work on both of them until one emerges as a clear
winner.  At that point, though, only the winner should be worked on.
This is not the case for XPath and Selectors, though.


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

As Yehuda notes, this probably doesn't do what you want if there's
another table preceding the context element's table in the document,
since it'll go from the first row in your table to the last row in the
preceding table.

You likely want the previous row in the same table.  This is trivial
in JS if your table has only a single tbody, and also trivial in
Selectors with the subject indicator in the Selectors 4 draft (use
"tr! + tr:scope", or with the alternate :has() formulation, use
"tr:has( + tr:scope )").  If you have multiple tbodys, it's still
really easy in JS (if you're at the first row in the tbody, go up one
level and check if there's a preceding tbody, if so return its last
row).  It can't be done in the current Selectors 4 draft, but will be
doable with some planned extensions (it requires a little bit of
thinking, but it's not too horrible with :has()**).

I believe that a proper XPath expression for this would be similarly
complicated to the Selectors version.  I won't attempt it, though I
welcome someone else to do so.

** :matches(
     tr:has(+tr:scope),
     tbody:has(+tbody>tr:first-child:scope) > tr:last-child )

If you really do want the full power of XPath's preceding axis,
however, that's not trivial to write in either JS or Selectors.  If
Selectors had a combinator for descendant-or-self, it would be a
fairly simple one-liner, though.


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

Could you explain why I'm wrong, rather than why you dislike what
you've assumed about me?  I can't do much about your assumptions of
me, but I am able to discuss whether things I've said are correct or
not.

~TJ

Received on Wednesday, 30 November 2011 22:35:47 UTC