W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [selectors-api] Summary of Feature Requests for v2

From: John Resig <jeresig@gmail.com>
Date: Wed, 23 Sep 2009 23:17:35 -0400
Message-ID: <730bab940909232017l7250eda8r29cb036377e89d5@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-webapps <public-webapps@w3.org>
Quick Summary of my opinions:

Matches Selector: Super-super useful - critical, in fact. We're not able to
remove jQuery's selector engine until this is implemented. I'm working with
the devs at Mozilla to get an implementation landed. Already have a test
suite in place.

Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.

If I can do:
document.querySelectorAll.call([document.getElementById("node1"),
document.getElementById("node2")], "div > span"); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).

Scoped Queries: Also critical. As it stands, in jQuery, we just punt
whenever does a query rooted to a DOM element and fallback to the old
selector engine.

Namespace Prefix Resolution: Indifferent.

--John


On Wed, Sep 23, 2009 at 7:51 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au>wrote:

> Hi,
>  I'm planning to look at beginning work on Selectors API v2 soon to add a
> number of requested features that didn't make it into the first version.
>  This e-mail is a summary of what is being considered, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865
>
> The suggestion is for being able to check if a given element matches a
> given selector.  There is already similar functionality provided by JQuery
> and Mozilla have begun working on an implementation for it in Firefox.
>
> For the basic case, this is fairly trivial.  The method just needs to take
> a selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>
> In this case, the div1 would be the reference element that is matched by
> :scope.  But we still need to determine how useful such functionality would
> be, and whether it's worth pursuing it in this next version.
>
>
> *Filtering NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
>
> The suggestion is for being able to take a NodeList, and filter the nodes
> to obtain a collection of just those that match a given selector.
>
> For example, being able to get a NodeList somehow, do something with it,
> and then filter it more to work with just a subset:
>
> e.g.
> var list = document.querySelctor("div>p");
> // Do something with list, before obtaining the subset
> subset = list.filterSelector(".foo");
> ...
>
> We need to find and document the possible use cases for this feature.
>
>
> *Scoped Queries*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
>
> This has been discussed extensively in the past.  Basically, the idea is
> that the selector would be evaluated in the scope of the element, in a way
> more compatible with how libraries like JQuery work.  This slightly
> different from the :scope pseudo-class proposal, see bug for details.
>
>
> *Collective Queries on NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
>
> The suggestion is to be able to run querySelector() and querySelectorAll()
> on NodeList, and have the result be the union of results in document order
> from running the method on each Element in the NodeList.
>
> e.g.
>
> list.querySelectorAll("p");
>
> Would be somewhat equivalent to running list[i].querySelectorAll("p"); for
>  on each element in the list, and then building an array with the union of
> distinct elements from all the results.  I've been told that similar
> functionality for this already exists in JQuery.
>
> I believe the expectation is that both NodeList.querySelector() and
> .querySelectorAll() would work.  The difference is that querySelector() on a
> NodeList would return a NodeList (unlike on Element which just returns a
> single element) containing the first matches from each node in the list.
> i.e. equivalent to running list[i].querySelector() on each node and then
> combining all results into an array.
>
> It also seems sensible to allow the new scoped methods to be used in an
> analogous way on NodeLists.
>
>
> *Namespace Prefix Resolution*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
>
> The most controversial issue of the lot.  Need to clearly document the use
> cases and evaluate the problems being solved, and determine if it's really
> worth addressing in this version.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>
Received on Thursday, 24 September 2009 03:18:36 GMT

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