Re: QSA, the problem with ":scope", and naming

On Thu, Oct 20, 2011 at 2:04 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/20/11 4:32 PM, Tab Atkins Jr. wrote:
>> 1. Run the :scope-carrying selectors across the document together,
>> automatically yielding a dom-ordered list.
>> 2. Run the :scope-absent selectors together, automatically yielding a
>> dom-ordered list.
>> 3. Find where the scoping element would be inserted in the #1 list,
>> and insert the entire #2 list there.
>
>  foo.find(":scope + div, :scope div")
>
> begs to differ.

Well, that would only cause a problem if there were also a
:scope-absent selector in the list, like:

foo.find(":scope + div, :scope div, span")

If they *all* carry :scope, then you can just run them all over the
whole tree and get the ordered set in the normal fashion.


> So does:
>
>  foo.find("span :scope ~ div, span > :scope div)
>
> (which is not quite as trivial to analyze).

Same here.

Yeah, it's possible to make it necessary to interleave the
:scope-carrying and :scope-absent sets, if you run the two separately
(perhaps because you can optimize the :scope-absent ones to fail when
the search would escape the subtree).

If you internally modify the :scope-absent selectors to start with
:scope and a descendant combinator (in other words, do the "add a
unique id" trick that selector engines do in this situation), and then
run it with all the rest, though, that disappears.  You might lose
some possible optimization (based on knowing you only need to search a
subtree), but not necessarily, and you're avoiding a potential
slowdown from having to interleave.


> You could try to look at the combinator following the part(s) that have
> :scope, but that can get tricky.

Yeah, I can see some possibilities, but they're not exhaustive.


> And worse yet, the current :scope proposals allow an arbitrary nodeset to be
> specified as matching :scope, at which point this whole thing is out the
> window.

QSA allows that (or plans to?).  Alex's find() proposal does not.  The
scoping element is solely the 'this' in .find.


> And yes, if you use a subject indicator then performance goes out the window
> too; you basically have to search the whole DOM.
>
> As long as you're ok with searching the whole DOM any time anything funny is
> happening, of course, there's no other performance issue here.  But then I
> suspect this will be slow to start with....

It was good enough for jQuery in the pre-QSA days, and it's still good
enough for jQuery now when it can't use QSA, I don't see why it's not
good enough for the rest of us.  We can do at least as good, and
probably still better.

~TJ

Received on Thursday, 20 October 2011 21:16:42 UTC