Sean Hogan wrote:
- 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
Honestly, className is not a "straight-forward" way to check whether an element matches getElementsByClassName. Similarly, "getElementById and id" doesn't work if xml:id is supported.
This is not to say that having a way to check whether an element matches a given selector might not be nice in some cases, but let's not overstate the case here.
These features aren't just in the specs and provided by the browsers, they are used frequently (well, not the last one).
The last one isn't used much because it basically doesn't work.
To not have Element.matchesSelector is to go against current standards and (I'm sure you will find) programmer expectations.
The latter, maybe. The former, no (in the realistic sense of violating current standards).
It's interesting that I have never heard any of the JS framework authors (who are some of the primary target audience for this specification) mention anything about matchesSelector...
In any case, I think Lachlan is right. This sounds like a reasonable addition for a future spec version, but not this one. (Specs need to have a feature freeze just like software does, and I think this is unarguably a feature.)
-Boris -Boris
