Re: XPath and find/findAll methods

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

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

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

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 22 November 2011 17:29:28 UTC