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/
