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

[selectors-api] Summary of Feature Requests for v2

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 23 Sep 2009 13:51:37 +0200
Message-ID: <4ABA0BC9.1000108@lachy.id.au>
To: public-webapps <public-webapps@w3.org>
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 Wednesday, 23 September 2009 11:52:21 GMT

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