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 <[EMAIL PROTECTED]> Date: Wed, 10 Jan 2007 11:06:20 +0100 Message-Id: <[EMAIL PROTECTED]> Cc: "Web API WG (public)" <[email protected]> To: Anne van Kesteren <[EMAIL PROTECTED]> 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/
