Re: [selectors-api] QSA and findAll definitions

Thank you both. That helps a lot. I figured el.querySelector(":scope +
div") would do the same thing as el.find("+ div").

Perhaps more examples in the spec that clearly demonstrate differences like
this between qSA() and findAll() would be helpful. I think some form of the
example that Tab gave would be a great addition.

Also, maybe we can clarify even further in the defintions for find() and
findAll(). Perhaps, rather than,

"... from the tree within which the context object is located."

It could be,

"... within the subtrees of the parent of the context object or the tree in
which the context object is located if there is no parent."

Compare this with qS[A]:

"... within the subtrees of the context object."

This is an attempt to make it clear that ancestors of the context object
will never be in the resulting set and need not be considered in
implementations. In other words, it seems to me that elem.find() will never
return ancestors of elem.


On Mon, Jun 10, 2013 at 10:53 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 6/9/13 7:35 PM, Timmy Willison wrote:
> >> I was a little confused. I realized something I already knew in that
> >> elem.querySelector[All] does limit the matched set to the descendants of
> >> element
> >
> > Right. But find() does not, for what it's worth, depending on the exact
> > selector used.  It can return sublings of the context object, for
> example,
> > as far as I can tell.  Hence the wording difference.
>
> Specifically, "el.find('+ div');" will work, and find the sibling
> <div> to the context element.  "el.querySelector(':scope + div');"
> will *not* work, because the results are first filtered to be only
> descendants of the context element.
>
> The wording is slightly confusing now, but in Selectors 4 terminology,
> selectors in find() are *relative*, but not *scoped*.  Selectors in
> qSA() are scope-filtered.  (They may also be relative - it's been a
> while since I read the spec, so I don't remember.)
>
> ~TJ
>
>