Re: [selectors-api] matchesSelector() Proposal (was: Call for Consensus - Selectors Last Call)

Sean Hogan wrote:
> Lachlan Hunt wrote:
>> Sean Hogan wrote:
>>> Gregory Reimer (the author of reglib) points out that 
>>> Element.matchesSelector would be useful for event delegation.
>>> See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector
>>>
>>> It would also neatly tie in with NodeFilter in DOM-Traversal, 
>>> facilitating something like a live querySelectorAll() during document 
>>> load.

I forgot to mention before that I already have an open bug for tracking 
this issue.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

>> It would be useful if you could elaborate upon those use cases.
> 
> Are you asking for a better explanation of the concepts or more specific 
> examples?

Well, you already explained the concept of event delegation below, but 
some examples would also be useful, especially real world examples.  Do 
any JavaScript libraries implement functionality similar to the 
matchesSelector proposal?  If so, then examples of those would also be 
useful.

>> How is that nonsensical?  Without having use cases presented, it's 
>> hard to justify the feature and even harder to make sure it's designed 
>> in the most optimal way for those use cases.
> 
> - The feature is already justified by the first paragraph of the 
> specification. It facilitates the performing of DOM operations on an 
> element that matches a selector.

There are other potential features that fit that description, but which 
weren't included in this version.  For example, NodeList filtering, 
scoped methods and namespace resolution, each of which will be 
reconsidered for the next version.

> - The feature is already defined in the specification as part of the 
> querySelector* methods. "The term 'matching Element node' refers to an 
> Element node that matches the group of selectors (selectors) that was 
> passed to the method". The only decision to be made is about the name.

That just means it will be somewhat easier to specify.  Although there 
are lots of other issues to consider which can make it slightly more 
complex, either for the spec and/or implementations. e.g.
* Defining how it works with :scope (as mentioned previously)
* Any potential security issues (there may not be any, but we need to
   be sure)

And potentially many others that get raised during implementation. 
Also, don't underestimate the cost of choosing an appropriate method name.

> - Event delegation plus Element.matchesSelector is a better match for 
> event registration that querySelectorAll.
> Say you want to add event handlers to elements that match a selector. If 
> you perform document.querySelectorAll(S1) and then addEventListener on 
> each found element, and then one such element (E1) is relocated in the 
> document in such a way that it no longer matches S1 then (presumably) 
> the handlers attached on E1 become invalid and need to be removed (and 
> perhaps different ones added).

Sure, if you're using event delegation, then I agree that a 
matchesSelector method could be useful.  But be aware that event 
delegation is just one possible solution to that problem.  XBL2 is 
another more flexible solution with features designed specifically for 
that.  Hopefully that will become available within a few years, but 
unfortunately, implementing it isn't yet a priority for implementers.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Monday, 8 December 2008 08:23:55 UTC