Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. wrote: > > > 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 >
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. wrote:
> On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky 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
> 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
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 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 wrote: > On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren 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
>From the perspective of building a selector engine, I think all selector
engines need something like .findAll, and not something like :scope.
On Tue, Oct 18, 2011 at 8:00 PM, Alex Russell wrote:
>
> No need to wait. We had something nearly identical for this in Dojo
> using an ID prefix hack. It looked something like this:
>
>(function(){
>var ctr = 0;
>query = function(query, root){
>root = root||document;
>var rootIsDoc = (root.nodeType == 9);
>var doc = rootIsDoc ? root :
> (root.ownerDocment||document);
>
>if(!rootIsDoc || (">~+".indexOf(query.charAt(0)) >=
> 0)){
>// Generate an ID prefix for the selector
>root.id = root.id||("qUnique"+(ctr++));
>query = "#"+root.id+" "+query;
>}
>
>return Array.prototype.slice.call(
>doc.querySelectorAll(query)
>);
>};
>})();
>
> This is exactly the same dance that ":scope" does.
>
>
Sizzle and Slick do the same thing. As far as I can tell, nwmatcher doesn't
deal with it. We can't just add :scope to all selections (for many reasons)
and adding just before QSA would require the same logic that Alex has
demonstrated above.
All of the selector engines do predictions at loadtime on whether QSA will
work. They continue differently beyond that, but one thing every library
has in common is a try/catch around the call to QSA that falls back to
manual parsing if it throws an exception (intentionally avoiding the need
for complete parsing before calling QSA). The point is it is a
misconception that selector engines parse selectors before delegating to
QSA. The number of things libraries want to do before getting to the QSA
call is very minimal. The one that hurts us all the most is this need for
scoping and ':scope' would simply never be used in a selector engine, since
the id trick already works everywhere. The case Alex wrote above is pretty
much the only case where the selector is parsed beyond checking for tag
only, id only, or class only and it is due to what all of the js libraries
has considered a design flaw in QSA. A method like findAll would fix that,
leaving as much parsing as possible in the hands of the browser.
PS - I should say I don't necessarily think the name 'findAll' would work. I
agree it should be short. The equivalent of querySelector would be find and
in library land 'find' selects more than one thing, but I'm not as concerned
about the name.
