Re: Call for Consensus - Selectors Last Call

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.
>

Received on Sunday, 7 December 2008 04:37:55 UTC