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 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: [XHR] remove user cancels request
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). +1 -- Glenn Maynard - Timmy
Re: QSA, the problem with :scope, and naming
On Oct 21, 2011, at 7:57 PM, Sean Hogan wrote: It was definitely not a design flaw in QSA. As Alex's sample code shows it is possible to get findAll() behavior using QSA. I think that further supports my argument. JS libraries have commonly considered this to be an oversight in the design of QSA, hence the need for ID hack. That is still true whether it was actually a design flaw or not. To do the reverse would involve calling document.findAll() then filtering for nodes that are descendants of the invoking node. I don't think anyone is interested in implementing the reverse in selector engines. The most useful thing would be elem.findAll(). No manual filtering required. But if findAll() is implemented they can advertise that avoiding non-standard pseudo selectors gives virtually native performance (on supporting platforms). I imagine this would be almost equivalent to deprecating them, which would be a win. This is extraneous. The implementation of custom pseudo selectors would be identical. - Timmy
