Re: XPath and find/findAll methods

On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon <robin@berjon.com> wrote:
> On Nov 22, 2011, at 17:05 , Tab Atkins Jr. wrote:
>> On Tue, Nov 22, 2011 at 4:16 AM, James Graham <jgraham@opera.com> wrote:
>>> Right, one of the issues with XPath is that the DOM3 XPath API is without
>>> doubt the worst API on the web platform. With a sane API there might be more
>>> demand for XPath since it can be used for things that the CSSWG are unlikely
>>> to ever allow in selectors for performance reasons. As Simon points out,
>>> there is even a preexisting API that does more or less the right thing and
>>> is implemented in IE and Opera.
>>
>> I believe there's a decent chance that we'll sprout a "batch
>> processers" selectors spec or profile of the existing spec to handle
>> things that are too expensive for normal CSS but perfectly fine when
>> run in JS.
>
> Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis...

I'm much less concerned about that than I am about authors having to
learn an entirely different selection syntax which is 90% identical in
functionality, just to get that 10% functionality on occasion.


>>> d - "//div[parent::*//a]";
>>
>> (d) can be done with the new subject indicator in the Selectors 4
>> draft:   a! > div  (syntax pending, but that's the general idea)
>
> I think that the example you show selects the <a> parent of a <div>, not <div>s that have parents containing an <a>.

Ah, I see.  I misread the XPath.

In that case, this isn't *yet* doable in Selectors, but we plan to
eventually support complex selectors in :matches(), at which point you
can do:

:matches(:scope a) > div

Or with a different syntax:

:has(a) > div

That should match the XPath example now, if I understand you correctly.

>>> There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other.
>>
>> They solve the same set of use-cases in the same way, with the only
>> difference being relatively minor abilities of each.  That definitely
>> makes them rivals.  ^_^  We don't need two selection mechanisms with
>> substantially different syntaxes.  XPath may be useful as a source of
>> more ideas to pull into Selectors, but that's it.
>
> Right, because since we have something that works why not invent another! Makes perfect sense to me.

I know you're being somewhat hostile because you like XPath and we're
essentially saying "ignore XPath, it's dead", but still, you're
arguing badly.

The web platform has a single selection syntax that has won without
question.  If it lacks some abilities, extending it is almost
certainly better for both implementations and authors than pulling in
a completely different selection syntax that is *almost* identical in
functionality but happens to include those abilities that were
lacking.  If this were any other pair of technologies, I highly doubt
you'd be able to make yourself argue that having two gratuitously
different syntaxes that authors have to regularly switch between based
on the exact property they want, and which can't be used together in
any simple way, is a good situation for us to create.  That's almost a
textbook example of valuing spec authors over everyone else.

~TJ

Received on Tuesday, 22 November 2011 17:58:15 UTC