Oh, one more thing I forgot to mention...

I'd still like to make optimizations for three common kinds of
* A single tag name ("li")
* A single class name (".external")
* Any selector with an ID in it ("div #sidebar")

The first two are important, in my opinion, because they'll get used a
lot with Element.(down|up|next|previous).  These are both easy
optimizations to make.

The last is important because we can rely on the uniqueness of IDs to
speed things up.  For instance, on the benchmark page you'll notice
that the "div#speech5" and "div #speech5" selectors are pretty
sluggish without XPath.  "div#speech5" has to grab all DIVs and find
the one with an ID of "speech5"; "div #speech5" has to grab *all
descendants* of all DIVs and find the one with an ID of "speech5."

A naïve approach would be to simply return $('speech5') in either of
these cases, but that approach would not guarantee that the result
matches the selector.  (For instance, the returned node might not be a
DIV or the descendant of a DIV.)  A compromise, I think, is to find
the ID and backtrack from there, asserting that it meets all of the
conditions preceding that token in the selector. (So for "div
div#speech5.dialog" it'd ask: does this node have a class name of
"dialog", a tag name of "div", and an ancestor with a tag name of
"div"? if so, it gets returned in a one-item array.  If not, an empty
array is returned.)

This approach would be much faster than the current approach, but
would be algorithmic hell. I am prepared to award the Nobel Prize of
Awesome to whomever manages to pull this off.


You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to