Re: QSA, the problem with ":scope", and naming

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

Received on Tuesday, 18 October 2011 21:32:42 UTC