W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: Call for Consensus - Selectors Last Call

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 07 Dec 2008 11:35:38 -0500
Message-ID: <493BFB5A.6080707@mit.edu>
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.)


Received on Sunday, 7 December 2008 16:36:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:13 UTC