Re: [selectors-api] QSA and findAll definitions
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@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
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. jackalm...@gmail.comwrote:
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@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
Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 1:15 PM, Timmy Willison timmywill...@gmail.com wrote: 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. It certainly can return ancestors. You just need the right combinators. The reference combinator defined in Selectors 4 http://dev.w3.org/csswg/selectors/#idref-combinators can move anywhere in the tree, including straight upwards. The use of the subject indicator, also defined in Selectors 4 http://dev.w3.org/csswg/selectors/#subject, can also move up the tree. Just throw away your notion that .find() does any scoping whatsoever. It doesn't; all it does is provide a reference element, which is matched by :scope and which is used to absolutize relative selectors. ~TJ
Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Just throw away your notion that .find() does any scoping whatsoever. Ok, will do. It doesn't; all it does is provide a reference element, which is matched by :scope and which is used to absolutize relative selectors. ~TJ
[selectors-api] QSA and findAll definitions
The wording of the QSA and findAll definitions are a bit confusing to me. Forgive me if I'm misunderstanding, but the definitions for querySelector[All] and find[All] seem to be partly reversed. First, the definition of subtrees seems clear enough: The term subtrees refers to the set of elements that are descendants of the specified context object. However, the definition for querySelector currently states: return the first matching Element node within the subtrees of the context object. Isn't that the definition for find? Element#querySelector does not limit matching to subtrees of the context object. `elem.querySelector(div)` will return all divs on the page, not just descendants of `elem`. I assume this was not meant to be changed here. find states: return the first matching Element node from the tree within which the context object is located. This sounds just like what querySelector is supposed to do. Element#querySelector returns results based off of the tree in which the element is located. Thanks, - Timmy
Re: [selectors-api] QSA and findAll definitions
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, but the selector itself is not relative. Sorry about that. I guess my only question now is what is the difference between the way .find[All] and .querySelector[All] relate to the context object? Why the wording difference? Thanks again, - Timmy On Sun, Jun 9, 2013 at 5:34 PM, Timmy timmywill...@gmail.com wrote: The wording of the QSA and findAll definitions are a bit confusing to me. Forgive me if I'm misunderstanding, but the definitions for querySelector[All] and find[All] seem to be partly reversed. First, the definition of subtrees seems clear enough: The term subtrees refers to the set of elements that are descendants of the specified context object. However, the definition for querySelector currently states: return the first matching Element node within the subtrees of the context object. Isn't that the definition for find? Element#querySelector does not limit matching to subtrees of the context object. `elem.querySelector(div)` will return all divs on the page, not just descendants of `elem`. I assume this was not meant to be changed here. find states: return the first matching Element node from the tree within which the context object is located. This sounds just like what querySelector is supposed to do. Element#querySelector returns results based off of the tree in which the element is located. Thanks, - Timmy
Re: [selectors-api] QSA and findAll definitions
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. -Boris
