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

So I spoke with Borris about this at some length offline yesterday and was
really shocked to discover that in the interest of supporting docs that do
not conform, there appears to be 100% implementation agreement in CSS (and
therefore qsa) that id selectors must match against all elements with the
same id and that getElementById must always return the first (which makes it
hyper easy by comparison to match).  This is in conflict with specs dating
way back in terms of whether what the spec says is normative - but its
definitely implemented that way everywhere.  We have submitted errata on
that, but if it helps shed some light on earlier comments, that's why.

He said earlier that it would be easy enough to optimize in the case that
there is only one element with a given id, but in other cases get element by
id would remain faster though not conforming with all css implementations or
existing rec intents.

I'm curious to hear comments on whether that would satisfy jquery et all as
well as what course of action they will take re: the disparity that now
apparently exists between css and jquery selector implementations of this.
Given that no current jquery app could possibly rely on this difference and
that jquery always reurns a list it seems like you could can parity, but
risk performance.
On Oct 20, 2011 5:06 AM, "Timmy Willison" <timmywillisn@gmail.com> 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>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.
>