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.
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?
Unfortunately I had assumed it was in the spec. I've looked now and
seen that it wasn't considered due to a lack of presented use cases,
which seems non-sensical.
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.
- 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.
- All the getElement* selectors are matched by straight-forward ways for
checking if an element-node matches the desired constraint.
e.g. getElementsByTagName and tagName, getElementById and id,
getElementsByClassName and className / classList
These features aren't just in the specs and provided by the browsers,
they are used frequently (well, not the last one).
To not have Element.matchesSelector is to go against current standards
and (I'm sure you will find) programmer expectations.
- 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).
You could of course use DOM Mutation listeners to detect when an element
or DOM-tree is removed, but how are you going to work out which event
handlers to remove if you don't have Element.matchesSelector?
None of this is an issue with event delegation.
The only reason for it not to be in the spec is if it is harmful.
AFAIK, no-one said it was harmful. It is too late for this proposal
to be added to this version of the spec, but it will be considered for
the next version.
The only complication I can see is supporting the :scope
pseudo-attribute.
Assuming the CSSWG includes the :scope proposal in the next version of
Selectors, and if there are use cases for which :scope would be useful
in a matchesSelector() function, we can investigate solutions to
address the issue.
