Re: Use cases for Selectors-API

Giovanni Campagna wrote:
>      - Selectors is designed to be fast to match, while XPath had no
>     such design criterion; as a result it's very easy to write
>     pathologically slow XPath queries, even by accident.  For
>     non-pathological cases, Selectors are still faster, whether because
>     of spec design choices or because browsers already heavily optimize
>     selector matching.
> 
> That is an issue for browser vendors, not spec writers.

And that attitude is exactly why there are XPath queries that just can't 
be fast.

> And I think that 
> if they optimized document.querySelectorAll("blockquote > p") they can 
> optimize document.evaluate("\\blockquote\p",...)

Sure, but as soon as you forget that leading \\ you lose, no?

> The problem are toolkits, not XPath. The more javascript you use, the 
> worse the performance, since JS is interpreted not compiled. If toolkits 
> didn't rewrite complex CSS selectors in XPath syntax, performance would 
> be similar.

I can guarantee you that CSS selector performance in Gecko is faster 
than XPath and is likely to stay that way indefinitely.

> You don't need selectors API for matching ".my_class" or "object" or 
> even "#my-id". Use getElement(s)ByClassName/TagName/Id

No, but as soon as you want "#mymaintext .my_class" you do.  And thi is 
hardly unknown CSS3 stuff.

> I meant that any new API is a problem beacuse authors don't learn 
> quickly. (and DOM3XPath is not new, selectors API instead is)

Authors are already using API like this through the toolkits; they'll 
immediately see speedups in their code and won't have much of a jump to 
use the API directly.

> Same old questions = same old answers?

Yes.  They seem to have been considered sufficient the previous times 
around.

> I don't think these are enough

You're always welcome to raise a formal objection, of course.

-Boris

Received on Saturday, 27 December 2008 18:53:00 UTC