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

On 20/10/11 8:42 PM, Lachlan Hunt wrote:
> On 2011-10-20 10:14, Sean Hogan wrote:
>> The primary use-case for matchesSelector() has been event-delegation,
>> and this is the same for matches(). More specifically, consider the
>> following scenario:
>>
>> jQuery adds a new event registration method that uses event delegation
>> to mimic the behavior of:
>> $(elem).find("> div > .thinger").bind(eventType, fn);
>> The new method is called proxybind(), and the equivalent of the above 
>> is:
>> $(elem).proxybind("> div > .thinger", eventType, fn);
>>
>> The event handling for proxybind() would invoke matches("> div >
>> .thinger", [elem]) on elements between the event target and elem to find
>> matching elements.
>
> It may not be too late to introduce that behaviour into 
> matchesSelector, with a switch based on the presence or absence of the 
> refNodes/refElement parameter.
>
> As currently specified, calling the following doesn't and shouldn't 
> prepend :scope.
>
>   el.matchesSelector("div .foo");
>
> This one also matches the prefixed implementations in browsers, since 
> most haven't started supporting :scope yet, and I don't believe 
> Mozilla's experimental implementation [1] has landed yet.
>
> As currently specified, calling this:
>
>   el.matchesSelector("div .foo", ref);
>
> Also doesn't prepend :scope automatically, but in that case, the ref 
> nodes do nothing useful. 

But this selector can still match elements. Admittedly I can't think of 
a use-case for this, but it is conceivable for someone to expect this to 
work without an implied :scope.

> Authors have to use :scope explicitly for them to be useful as in 
> something like:
>
>   el.matchesSelector(":scope div .foo", ref);
>
> Or
>
>   el.matchesSelector("div:scope .foo", ref);
>
> One thing we could possibly do is define that if ref nodes are passed, 
> and the selector doesn't explicitly use :scope, then effectively 
> prepend ":scope ".  This would be exactly the same behaviour as that 
> discussed for .findAll();
>
> That wouldn't break compatibility with anything, optimises for a 
> common case and avoids introducing two separate match methods.
>

I don't see the need for findAll(), but if it is added I think it should 
always imply ":scope " at the start of a selector, and I think a 
separate match method that does the same should be added. To do 
otherwise seems too ambiguous for a DOM API.

> e.g.
> el.matchesSelector("div .foo");             // No ref, no magic :scope
>
> el.matchesSelector("div .foo", ref);        // Implied, magic :scope
> el.matchesSelector("+.foo", ref);           // Implied, magic :scope
>
> el.matchesSelector(":scope div .foo", ref); // Explicit, no magic :scope
> el.matchesSelector("div:scope .foo", ref);  // Explicit, no magic :scope
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=648722
>

Received on Thursday, 20 October 2011 10:29:39 UTC