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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 29 Nov 2011 16:52:40 -0800
Message-ID: <CAAWBYDBzvDVaxoakk1Ng9_qAVyLmqbc92P+NfM2nYadZtJVZpg@mail.gmail.com>
To: João Eiras <joaoe@opera.com>
Cc: public-webapps@w3.org
On Tue, Nov 29, 2011 at 4:16 PM, João Eiras <joaoe@opera.com> wrote:
> On Tue, 29 Nov 2011 20:42:59 -0000, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> My stated goal was to argue that working on XPath is a bad idea
> You can argue that it's wasted effort or duplicated by CSS Selectors
> (although XPath is already specified, implemented and deployed unlike the
> new Selector features), but it goes a long way for you to claim it is a
> *bad* idea.
> I still think you are underestimating XPath. There are things possible in
> XPath today that will never be possible with Selectors in the unforeseeable
> future, like a parent selector, or doing a case insensitive substring match
> of a node's text content (from any descendant).

Incorrect.  The Selectors 4 editor's draft contains the same
functionality as a parent selector:  "A/parent::B" in XPath is the
same as "B! > A" in Selectors.  I talked about this in my email.
Matching based on text contents has been proposed multiple times, but
has always been shot down due to performance concerns for CSS.  A
profile of Selectors designed for JS (querySelector or find) wouldn't
have that same worry.

> If you're suggesting forking Selectors into the ones used in stylesheet, and
> the others used in the Selector API, then it is repeated effort and a *bad*
> idea because those use cases are already covered today with already deployed
> XPath and its DOM 3 XPath API, which is convoluted and hard to use, which is
> what people are trying to make friendlier. And it would definitely confuse
> everyone, because then developers would need to know which features they can
> use in stylesheets and which they cannot.

You are looking at the cost of one possibility, and ignoring the
other.  If we go your way, developers have a single set of Selectors
which they can use in CSS and JS, plus a set of XPath they can use in
JS, but they can't combine the two JS solutions in any reasonable way,
so the features that each have can't be used together, and for the
parts that are duplicated between the two they have to learn two
different syntaxes.  I think it's impossible to argue that that's not
at least as confusing; I will argue further and say that it's
substantially more confusing.

This argument in general seems to have an underlying assumption that
XPath is necessarily more powerful than Selectors.  This is incorrect.
 Most of the useful bits of XPath and Selectors are isomorphic.  XPath
has a few things that are more powerful, such as a general mechanism
for matching nodes based on simple math or string manipulation, but
they can be duplicated quite easily in JS.  Selectors has a few things
that are more powerful, such as most of the pseudoclasses, but these
are *not* generally easily duplicable in JS.  For example, handling
something "simple" like :nth-col() requires snooping through the
entire preceding table structure for row/colspan cells that would
alter the numbering beyond simple sibling-counting.

So, the simple hack of doing
"document.evaluate(...).filter(function(elem){...})" doesn't work so
well if you're patching XPath into the union of features, but it
*does* work pretty well for patching Selectors into the union of

My overriding point is that the mental cost of supporting two nearly
identical languages merely because they both already exist and each
has slightly different functionality than the other is horrible, and
we should avoid it if at all possible.  It is roughly equivalent to
having, say, a <captionedvideo> element that accepts subtitles but
doesn't have controls, and a <usablevideo> that has controls but not
subtitles.  Even if you can achieve any given feature by choosing one
or the other, it's much less useful (and much more confusing) to have
the two separate than it would be to just combine them.  It is
absolutely worthwhile to expend effort in raising up one language to
the union or near-union of the feature-set (or achieve the union some
other way, like cheap/easy JS integration with Selectors) than to
attempt to pursue both simultaneously.

Received on Wednesday, 30 November 2011 00:53:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC