W3C home > Mailing lists > Public > public-webapi@w3.org > December 2006

Re: Selectors API naming

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 14 Dec 2006 23:00:39 -0800
Message-Id: <1375E322-5289-4F66-AF76-041D994CCF43@apple.com>
Cc: Dave Massy <Dave.Massy@microsoft.com>, Anne van Kesteren <annevk@opera.com>, public-webapi@w3.org
To: Charles McCathieNevile <chaals@opera.com>

On Dec 14, 2006, at 10:50 PM, Charles McCathieNevile wrote:

> On Fri, 15 Dec 2006 11:58:16 +0530, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>> On Dec 13, 2006, at 9:05 AM, Dave Massy wrote:
>>> Moving to public-webapi@w3.org
>>> I don't think we are tied to a particular name for this, I think  
>>> getElementsByGroupOfSelectors might be a little excessive :)  
>>> However we'd just like the name to more clearly reflect the  
>>> functionality rather than a generic sounding matchAll() which  
>>> isn't really intended for generic use. It's our belief that it is  
>>> important for names to reflect what they do where possible.  
>>> Having a short name might save us all a few keystrokes but it is  
>>> less clear to developers what the call is doing and can create  
>>> bigger problems.
>> I think a short but clear name would be select(). Unfortunately  
>> that is taken by Microsoft's nonstandard XPath API. match() seems  
>> like a decent next-best choice. The idea is to make this a common  
>> idiom with a convenient name so people don't have to go to crazy  
>> lengths like making $() or $$() functions to avoid using it.
> I can live with something like matchSelector / matchAllSelectors if  
> that would solve the problem (I am also happy with the current  
> names). But I am really not interested in a long discussion about  
> the name - at the end of the day we are almost guaranteed to pick  
> something not quite right, so let's do that early in the morning  
> and spend the day doing real work...

I can live with the current names in the document.

Received on Friday, 15 December 2006 07:01:09 UTC

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