On 10/18/11 5:23 PM, Brian Kardell wrote:
This is not that easy. Especially because you can reach all DOM objects
from elements, so you have to lock down the entire API somehow.
Right, you would need essentially, to pass in a node list which
iterated 'lite' read-only elements.
So the script would not get an actual DOM tree and not run in the Window
scope? The objects would not have an ownerDocument? What other
restrictions would they need to have?
Maybe I'm way off, but actually seems not that difficult to
imagine the implementation.
If we're willing to pass in some totally-not-DOM data structure and run
in some sandbox scope, then sure.
div .x:foo(.bar) span
The normal CSS resolution would be to get the spans, narrow by .x's
then throw what you have so far to the filter, removing anything that
returned false and carrying on as normal.
Normal CSS selector examines the .x part for each span as it finds it.
Otherwise selectors like "#foo > *" would require building up a list of
all elements in the DOM, no?
The slowness as I see it would be that the filter would yes, call across the
boundary and yes
have to build some intermediate and evaluating anything too complex in
the filter in that would be very slow by comparison probably - but you
don't have to do "much" to be useful... Is there something in that
pattern that I am missing in terms of what you are saying about
identifying what has changed out from underneath you?
_If_ the filter runs JS that can touch the DOM, then in your example for
every span you find you'd end up calling into the filter, and then you
have to worry about the filter rearranging the DOM under you.
As far as I can see it doesn't invalidate anything that already exists in
CSS/selector
implementations in terms of indexes or anything
At least the querySelectorAll implementations I have looked at (WebKit
and Gecko) traverse the DOM and for each element they find check whether
it matches the selector. If so, they add it to the result set.
Furthermore, selector matching itself has to walk over the tree in
various ways (e.g. to handle combinators). Both operations right now
assume that the tree does NOT mutate while this is happening.
-Boris
