W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

Re: Proposal: getElementsBySelector()

From: Christophe Jolif <cjolif@ilog.fr>
Date: Tue, 06 Feb 2007 14:07:36 +0100
Message-ID: <45C87D98.5000805@ilog.fr>
To: Charles McCathieNevile <chaals@opera.com>
CC: Anne van Kesteren <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>

Charles McCathieNevile wrote:
> On Sun, 28 Jan 2007 13:41:10 +0530, Anne van Kesteren <annevk@opera.com> wrote:
>> Given the input from Björn I suppose there's no real need for a method
>> that returns a single element node (assuming implementations make that
>> optimization). Given that, I propose we rename .getAll() to
>> .getElementsBySelector() and drop .get() (on both Document and Element).
>> One advantage is that it's consistent with the naming people already use
>> for custom written functions that have this functionality. In theory it's
>> also not harder to type than .getElementsByTagName(). The only thing that
>> makes it differ from the other getElementsBy* method(s) is that it doesn't
>> return a live NodeList. I don't see that as a major problem.
>> If there are no strong objections I'll implement this in the specification.
> Not having heard strong objections, and having had support for 
> getElementsBySelector() that is at least as strong as anything else, I think (with 
> my chair's hat) this can be taken as the current resolution of the naming debate.
> Which would also resolve ISSUE-110.
> Any objections?


And I notice dojo has a

dojo.getElementsByClass function, so it looks like very similar to the 
current naming for a similar functionality in existing widespread 
toolkit out there.

Received on Tuesday, 6 February 2007 13:06:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC