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

On Tue, Oct 18, 2011 at 5:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

They would run in their own sandbox and they would have access to the
parameters passed into the function by way of pattern.  I think that
that pattern would look a lot like jquery's selector plugin pattern
something like: The match itself, the index of the match, the
arguments to the selector itself. The 'match' in this case wouldn't be
a mutable DOM element.  You can give it a smaller API by saying that
the 'lite' version of the element that is passed in has no properties
which might give you something mutable - or you can say that all
methods/properties would also return immutable shadows of themselves.
I would be happy to walk through more detailed ideas in terms of what
specifically that would look like if there were some kind of initial
"yeah, that might work - its worth looking into some more" :)


>> 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?

I'm not sure that I understand the distinction of what you are saying
here or if it matters.  My understanding of the webkit code was that
it walks the tree (or subtree) once (as created/modifed) and optimizes
fastpath indexes on classes, ids and tags (also some other
optimizations for some slightly more complex things if I recall).  I
would have expected the querySelector** stuff to re-use that
underlying code, but I don't know - it sounds like you are saying
maybe not.

>
>> 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.

Yes - it absolutely can NOT mutate while this is happening, but it
shouldn't right?  It would be kind of non-sensical if it did.  It
doesn't have to mutate in order to be useful - even in jQuery's model,
its purpose is in order to determine what _should_ mutate, not to do
the mutation itself.

>
> -Boris
>
>

Received on Tuesday, 18 October 2011 22:06:19 UTC