Re: [selectors-api] Why no querySelector(All) on DocumentFragments?

On 12/03/2008, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> liorean wrote:
>  > In this traversal scheme, querying the selector is still done from the
>  > document node, just excluding all subtrees except for the subtree of
>  > the element we're querying on.
>  >
>  > Another alternative is of course to do the matching backwards,
>  > beginning with trying to match the last simple selector in the
>  > selectors on each of the elements of the subtree in question, then
>  > traversing the tree in upwards direction.
>
> Indeed.  I believe the backwards approach is what UAs actually do, and
>  what makes the most sense to do.  That is, the real question is whether
>  there is a subset of the maximal connected subtree containing the given
>  node (the one on which querySelector is being called) such that this
>  subset consists of nodes which match the various sequences of simple
>  selectors involved, and are positioned as required by the combinators,
>  with the element matching the rightmost sequence of simple selectors a
>  descendant of the given node.  If so, that element matches the selector.

Isn't this approach potentially much more resource intensive though?
Consider a selector like "body > div span". If we're doing this query
on an element with thousands of elements in it's subtree, of which
large numbers are spans, then we'd be repeating the match for the
second simple selector on a whole lot of elements multiple times, but
have to discard almost all of those matches because the parent element
doesn't match the first simple selector. Even though this could be
memoised so that the second selector only has to be match to any
single element once, it seems like doing it the other direction is
less likely to have pathological cases.

>  If Selectors does not define this sort of thing (and as I recall it
>  actually doesn't), then selectors api might need to.  It would make the
>  most sense to define this in Selectors, however.

The Selectors spec doesn't really deal with the DOM though. To me it
seems the Selectors API is more appropriate place to have a spec
relating to DOM relations.

Also, aren't selectors intentionally written so that they can be
applied either forwards or backwards depending on which context
they're used within? (i.e. forwards makes more sense for applying CSS
to a node tree, while backwards makes more sense for testing if a node
conforms to a selector or not .)
-- 
David "liorean" Andersson

Received on Wednesday, 12 March 2008 22:59:43 UTC