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

RE: Selectors API naming

From: Dave Massy <Dave.Massy@microsoft.com>
Date: Tue, 19 Dec 2006 12:35:17 -0800
Message-ID: <9028F8A4183B97499A2949FD6DED8B8913F73CD6@winse-msg-01.segroup.winse.corp.microsoft.com>
To: Charles McCathieNevile <chaals@opera.com>, Web API public <public-webapi@w3.org>
CC: Chris Wilson <chris.wilson@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Tina Duff <tinad@microsoft.com>
1. Other Issues. 
It'd be great to have more detail and scenario on NSResolver. It appears to allow elements within the document to have different prefixes than things in the style sheet. For example if we map html as the prefix for XHTML in our document then we’d write it like:
But then we can write a selector such as:
	“h|table > h|tr > h|td”
With a NSResolver that maps h to the same namespace as the html in the primary document. This seems potentially confusing.

As I mentioned previously a more complete example of staticNodeList usage would also be appreciated.

2. Naming
getElementBySelector/getElementsBySelector is the only proposal we think is acceptable. match/matchAll is not appropriate for a specific DOM method and matchSelector/matchAllSelectors isn't really much of an improvement. 
I'm concerned the group appears to believe naming is not important based on the belief that there is no such thing as the perfect name. While it is probably true that there is no such thing as a perfect name we have to think about the lives of web developers and the challenges they face. For these people consistent naming helps them find their way around the APIs and have some idea of what to expect from them. Members of this group may be fine with naming something xabcdexy() but I'm not sure that this group is really representative of the average web developer.

I'm more than familiar with "shipping is a feature" :) but shipping the right thing at the right quality level is also important. We do believe the functionality outlined in this spec is useful and want it to move forward as quickly as it can. However we also want to ensure it is clear, easy to use and easy to understand.


-----Original Message-----
From: Charles McCathieNevile [mailto:chaals@opera.com] 
Sent: Tuesday, December 19, 2006 8:52 AM
To: Web API public
Cc: Chris Wilson; Dave Massy; Anne van Kesteren
Subject: Re: Selectors API naming

OK folks,

Let's get this in perspective. We are trying to publish this document as a  
last call, and get on with the dozen other documents we are meant to get  
done in the next year. So I have two questions I would like answers on:

1. Does anyone see any other issue in the current draft that should be  
2. For the following options, do you consider the names "fine", "not great  
but acceptable", or "unacceptable"?

    If and Only If you consider all 3 names are so bad as to be  
unacceptable, please propose an alternative.

While getting naming perfect is a great thing, I don't know of it ever  
being done before. "Shipping is a feature", as a friend who was a product  
manager at a Redmond-based software company used to remind me, and if we  
can't get nomenclative perfection then I suggest we at least enhance the  
"shipping" side of our feature list...


Chaals (wearing a slightly ill-fitting chair's hat)

   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9 now! http://opera.com

Received on Tuesday, 19 December 2006 20:35:34 UTC

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