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

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

From: Sean Hogan <shogun70@westnet.com.au>
Date: Fri, 25 Nov 2011 10:19:56 +1100
Message-ID: <4ECED11C.6040001@westnet.com.au>
To: Yehuda Katz <wycats@gmail.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps@w3.org
On 24/11/11 10:52 AM, Yehuda Katz wrote:
>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan <shogun70@westnet.com.au 
> <mailto:shogun70@westnet.com.au>> wrote:
>
>     On 23/11/11 12:17 AM, Boris Zbarsky wrote:
>
>         On 11/22/11 6:50 AM, Lachlan Hunt wrote:
>
>             Last time we had this discussion, you had a desire to keep
>             the name
>             prefixed until the refNodes and :scope stuff was
>             implemented [1]. What's
>             the status on that now?
>
>
>         The status is that I've given up on the :scope discussion
>         reaching a conclusion in finite time (esp. because it sounds
>         like people would like to change what it means depending on
>         the name of the function being called) and would be quite
>         happy to ship an implementation that only takes one argument.
>          Web pages can use .length on the function to detect support
>         for the two-argument version if that ever happens.
>
>
>     Are there any issues with:
>
>     - If you want to use selectors with explicit :scope then you use
>     querySelector / querySelectorAll / matchesSelector.
>
>     - If you want to use selectors with :scope implied at the start of
>     each selector in the selector list (as most js libs currently do)
>     then you use find / findAll / matches.
>
>
>     The alternative option (find / findAll / matches can accept
>     explicit :scope, but will otherwise imply :scope) seems to be
>     where all the ambiguity lies.
>
>
> What exact cases are ambiguous with "find/findAll/matches can accept 
> explicit :scope, but will otherwise imply :scope"?
>
>

This has been raised before, but I'll restate it here.

How should the selector be expanded in
     elt.findAll("div span, div :scope span")?

The straight-forward interpretation of "implies :scope unless it is 
explicit" is to not expand this, thus:
     "div span, div :scope span"

But with that interpretation
     elt.findAll("> div span, div :scope span")
will throw an error, although
     elt.findAll("> div span"); elt.findAll("div :scope span");
is allowed.

If this isn't to throw an error then a more complex definition is 
required which can apply a different rule for implying :scope in 
different parts of the selector argument. This is sure to be confusing 
for anyone reading the code.

OTOH, if find / findAll  always implies :scope there isn't this problem. 
Moreover, that is what people will expect if they are used to jQuery's 
find() and equivalents in other JS libs.

This makes for a fairly straight-forward explanation of usage:

- If you want to use selectors with explicit :scope then you use 
querySelector / querySelectorAll / matchesSelector.

- If you want to use selectors with :scope implied at the start of each 
selector in the selector list (as most js libs currently do) then you 
use find / findAll / matches.
Received on Thursday, 24 November 2011 23:20:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT