- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 07 Dec 2008 11:35:38 -0500
- To: Sean Hogan <shogun70@westnet.com.au>
- CC: public-webapps@w3.org
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
Received on Sunday, 7 December 2008 16:36:23 UTC