Re: Publishing Selectors API Level 2 as an FPWD?

On 1/11/10 1:24 AM, Sean Hogan wrote:
> That's correct. jQuery's $(element).find("div") is the equivalent of
> SelectorsAPI2's element.querySelectorAll(":scope div") or

So in fact jquery can simply implement Element.find in terms of 
querySelectorAll by just prepending ":scope " to the selector string, 
right?  Note that this happens to work even for the "> div" case (by 
converting the selector to ":scope > div", which is what jquery means).

So the "> div" thing doesn't seem to require preparsing (modulo commas 
in the selector; was that the key point?).  Of course the jquery 
selectors that aren't in CSS do (or possibly post-parsing depending on 
how it's implemented).

> My point is that jQuery's $(element).find("> div") isn't supported
> (without pre-processing by the JS lib) by element.queryScopedSelectorAll().

...

> element.queryScopedSelectorAll(":scope > div") generally becomes
> element.parentNode.querySelectorAll(":scope > div", element) which is
> the same as
> element.querySelectorAll(":scope > div", element) or even
> element.querySelectorAll(":scope > div")

That's what I'm confused about.  Does implementing element.find("> div") 
as element.queryScopedSelectorAll(":scope > div") not do what the 
current jquery code does?  If not, how do they differ?

I'm still confused about queryScopedSelectorAll, though. It sounds from 
your example like queryScopedSelectorAll just prepends ":scope " to the 
whole query string and then calls querySelectorAll on the parentNode of 
the scope node, with the scope node passed in as the optional argument.  So:

   element.queryScopedSelectorAll(myStr)

is the same as:

   element.parentNode.querySelectorAll(":scope " + myStr, element);

is that correct?

-Boris

Received on Monday, 11 January 2010 07:40:35 UTC