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
