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

My first priority would be "Matches Selector", and see to that
it fulfills the needs for event delegation.

Best regards
Mike Wilson

Lachlan Hunt 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 Wednesday, 23 September 2009 12:46:38 UTC