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

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

From: Mike Wilson <mikewse@hotmail.com>
Date: Wed, 23 Sep 2009 14:45:51 +0200
To: "'public-webapps'" <public-webapps@w3.org>
Message-ID: <008001ca3c4b$c9250220$0a01a8c0@mikedeskxp>
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

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