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
Email: [EMAIL PROTECTED]
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at