W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 20 Oct 2011 21:29:03 +1100
Message-ID: <4E9FF7EF.7080508@westnet.com.au>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: Jonas Sicking <jonas@sicking.cc>, Alex Russell <slightlyoff@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>, John Resig <jeresig@gmail.com>, Paul Irish <paulirish@google.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC