On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote:

Anne van Kesteren wrote:
I read those. That was long after this was initially discussed though. And also around the time I stopped being the active editor of the specification.

Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but the W3C list search is crappy enough that I can't find the posts... In fact, the only thread on the matter I can find is the "ACTION-87: Selectors API" thread (announcing that you plan to start working on the spec at) at <http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html >. Was that it?

In any case, the static implementation was considerably more complicated in Gecko, I suspect performance is a wash in most cases, though it's easy to create examples that are much faster with one or the other approach.

Live lists will almost certainly be slower in the face of DOM mutation concurrent with iterating the list. I don't know of any reason things would be different in Gecko.

In the case of Selectors API especially, a fairly likely use case is to mutate the DOM while iterating the list - imagine finding all divs with a particular class name, attaching behavior, and then removing the class so that behavior is not accidentally added more than once. This would be terrible for most conceivable live list implementations. Complex selectors (involving indirect adjacent combinators for instance) would make things even worse - even DOM mutations that don't affect the contents of the list may force invalidation of any caches or else a complex calculation to prove they don't change the contents of the list.

This is the reason I originally reported that live lists are likely to be a performance issue for some common uses of this API.


Reply via email to