Re: Selectors API naming

Currently the following methods exist:

  * document.getElementsByTagName()
  * document.getElementsByName() (HTML only)
  * document.getElementById()

The following method is proposed by the WHATWG:

  * document.getElementsByClassName()

These four methods all return a _live_ NodeList meaning that when  
something in the DOM is changed the variable that holds the NodeList is  
changed accordingly, if needed.

If we would name the new pair as follows:

  * document.getElementBySelector()
  * document.getElementsBySelector()

They would not be consistent with the previous four mentioned methods as  
they would not return a live NodeList but a StaticNodeList. Which means  
that when an attribute value changes the StaticNodeList does not need to  
be updated for a group of selectors that uses an attribute selector  
somewhere.

These names would also be slightly confusing as they would not take a  
selector but rather a group of selectors. I suppose the group in favor of  
these methods find that acceptable. I wonder if they find the  
inconsistency with the other DOM methods to be acceptable as well.  
Personally I don't really like that.


It seems that libraries find there's a need to provide shortcuts for the  
several of the above mentioned methods (notably document.getElementById  
and document.getElementsByTagName). Several authors have argued that they  
don't see a need for such a thing but no "evidence" has been provided. No  
evidence to the contrary either, though.


I'm personally not really convinced by the autocomplete argument. I don't  
really think it's good language design to assume there's such a thing.


I'm still leaning towards not changing the draft with regard to naming for  
reasons mentioned above, but if someone can tackle the problems mentioned  
above I'm willing to reconsider.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 21 December 2006 21:17:55 UTC