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

RE: Selectors API naming

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Tue, 19 Dec 2006 12:44:13 -0800
To: Dave Massy <Dave.Massy@microsoft.com>
Cc: Web API public <public-webapi@w3.org>
Message-ID: <OFCD0A8B08.744F9E3A-ON88257249.0071C797-88257249.0071E978@us.ibm.com>
I agree with the Microsoft folks on this thread.


Jon Ferraiolo <jferrai@us.ibm.com>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865

             Dave Massy                                                    
             soft.com>                                                  To 
             Sent by:                  Charles McCathieNevile              
             public-webapi-req         <chaals@opera.com>, Web API public  
             uest@w3.org               <public-webapi@w3.org>              
                                       Chris Wilson                        
             12/19/2006 12:35          <chris.wilson@microsoft.com>, Anne  
             PM                        van Kesteren <annevk@opera.com>,    
                                       Tina Duff <tinad@microsoft.com>     
                                       RE: Selectors API naming            

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

(image/gif attachment: graycol.gif)

(image/gif attachment: pic29237.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 19 December 2006 20:44:45 UTC

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