Re: Selectors API updates

I have to agree with Robin here. The new names suggested do not address
the concerns raised around the original naming in the specification. 
Naming should be:
 a) descriptive of the functionality
 b) in line with conventions for existing DOM APIs such as
getElementbyID

Looking at the feedback on
http://lists.w3.org/Archives/Public/public-webapi/ and Anne's blog entry
at http://annevankesteren.nl/2006/12/selectors-api-naming it seems that
the majority of people would agree with these principles and the
suggested names based on getElementBySelector. I know not everyone is in
agreement and some people wish to save keypresses but I really think we
should be taking note of feedback from the majority and follow the above
principles.

Thanks
-Dave




From: Robin Berjon <robin@berjon.com> 
Date: Wed, 10 Jan 2007 11:06:20 +0100
Message-Id: <A204A009-EE2B-49F8-9F34-669995057FC5@berjon.com> 
Cc: "Web API WG (public)" <public-webapi@w3.org> 
To: Anne van Kesteren <annevk@opera.com> 

On Jan 09, 2007, at 23:08, Anne van Kesteren wrote:
> I updated the Selectors API specification today and added  
> equivalent methods for element nodes. It didn't make much sense to  
> me to postpone this.
>
> I resolved the naming debate by going for:
>
> * Document.get()
> * Document.getAll()
> * Element.get()
> * Element.getAll()
>
> These names are short, don't clash with autocomplete and provide a  
> superset of the functionality given by the other get* methods.

Sorry, I don't wish to reopen the naming debate, but these really  
don't strike me as the ones closest to consensus (aside from being  
dreadful picks). I think there are a bunch of names that people don't  
like but can live with, these are just pure nonsense. I certainly  
know that while I would have dropped the ball on any number of bad  
options, if these stay in the draft I will request formal objection  
from my AC Rep.

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 10 January 2007 18:18:39 UTC