Ken Snyder a écrit :
> Yes, it was very slow for me too with any of the "nth-" predicates.  
> That nth routine relies on counting the number of previous siblings FOR 
> EVERY NODE.  I'm not sure if that is avoidable, but I've added the 

Yeah, you're O(n²) on this, and I think I found a way to be O(n) quite
simply.  I'll let you guys know...

> first and last element separately is great, but not such a great 
> practice when trying to separate presentation from logic with JS.

Plus, you can use :first-of-type and :last-of-type or :first-child and
:last-child to achieve identical selection.

> And :empty seems tricky in XPath too. So Christophe, keep us posted with 
> any XPath magic you have up your sleeve....  This is it from me for now 
> with $$.

As for XPath, I do need to see whether we can achieve something
efficient with XPath (building a global AND-based expression, much like
the raw-OR version of include, would do nicely I guess).

I am concerned with :not requiring a each/include, which is O(n²) as
well, thus is very slow.  I am thinking of another way to build the
resulting set.  If worse comes to worst, relying on the raw-OR variant
of include *might* help in this case.

Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain

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

Reply via email to