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

On 20/10/11 12:39 AM, Timmy Willison wrote:
> >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 <slightlyoff@google.com 
> <mailto:slightlyoff@google.com>> 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 <http://root.id> = root.id
>     <http://root.id>||("qUnique"+(ctr++));
>                                    query = "#"+root.id
>     <http://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.
>

It was definitely not a design flaw in QSA. As Alex's sample code shows 
it is possible to get findAll() behavior using QSA. To do the reverse 
would involve calling document.findAll() then filtering for nodes that 
are descendants of the invoking node.

Clearly JS libs aren't going to switch from implied :scope to explicit 
:scope.

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.

> 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.