w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Selectors API Method Names
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: chaals@opera.com, schepers@w3.org
This questionnaire was open from 2007-07-25 to 2007-08-01.
14 answers have been received.
Jump to results for question:
1. Method Names
This is a poll to decide the method names of the Selectors API spec. It is open to all WebAPI Working Group members, and the results will be visible to the public (since this group has chosen to have high public transparency).
Please assign an order of preference for each name-pair choice, using each number only once. The rank will be used to calculate the relative support for each choice. The winner of this poll will be the choice with the lowest numerical value of the summed results.
"Don't mind" will be taken as a "concur" for that choice, and will be assigned a rank of 3 for purpose of calculation (a mildly positive neutral preference).
"Don't want" indicates a very strong objection to the name pair, and will be assigned a rank of 7 for purpose of calculation. If a particular choice is wholly unacceptable to you, please choose "Don't want", and give a technical rationale below.
Summary
| Choice | All responders | |||||||
|---|---|---|---|---|---|---|---|---|
| Don’t mind | Don’t want | Ranked 1 | Ranked 2 | Ranked 3 | Ranked 4 | Ranked 5 | Ranked 6 | |
| Single return value: selectElement() List of return values: selectAllElements() | 2 | 2 | 2 | 5 | 3 | |||
| Single return value: selectorQuery() List of return values: selectorQueryAll() | 4 | 1 | 2 | 4 | 2 | 1 | ||
| Single return value: selectorQueryOne() List of return values: selectorQuery() | 3 | 1 | 2 | 2 | 6 | |||
| Single return value: querySelector() List of return values: querySelectorAll() | 4 | 2 | 1 | 3 | 4 | |||
| Single return value: matchSelector() List of return values: matchSelectorAll() | 4 | 2 | 2 | 2 | 1 | 2 | 1 | |
| Single return value: getElementBySelector() List of return values: getElementListBySelector() | 2 | 3 | 6 | 2 | 1 | |||
Details
| Responder | Single return value: selectElement() List of return values: selectAllElements() | Single return value: selectorQuery() List of return values: selectorQueryAll() | Single return value: selectorQueryOne() List of return values: selectorQuery() | Single return value: querySelector() List of return values: querySelectorAll() | Single return value: matchSelector() List of return values: matchSelectorAll() | Single return value: getElementBySelector() List of return values: getElementListBySelector() | Rationale |
|---|---|---|---|---|---|---|---|
| Lachlan Hunt | Ranked 2 | Ranked 1 | Ranked 5 | Ranked 4 | Don’t want | Ranked 6 | http://lists.w3.org/Archives/Member/member-webapi/2007Jul/0032.html |
| Jonas Sicking | Don’t want | Ranked 3 | Ranked 4 | Ranked 1 | Ranked 5 | Ranked 2 | selectElement is too similar to selectNode and will probably be confusing for authors. selectorQuery is a noun rather than a verb. querySelector is short, a verb and it's obvious that it involves selectors. matchSelector sounds like it should return a boolean. getElementBySelector follows naming conventions and is easy to remember. Downside is that it's long and that it can be confusing that it doesn't return a live list. |
| Doug Schepers | Ranked 2 | Ranked 4 | Ranked 6 | Ranked 3 | Ranked 5 | Ranked 1 | Please let this end. |
| Björn Höhrmann | Don’t want | Don’t mind | Don’t mind | Don’t mind | Don’t mind | Don’t mind | In http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0098 I explained why the name or names need to include 'css' or 'selector'. |
| Maciej Stachowiak | Ranked 5 | Ranked 3 | Ranked 4 | Ranked 1 | Ranked 2 | Don’t want | Don't want rationale for getElementBySelector: name is much longer than the other options. |
| Chaals Nevile | Don’t mind | Ranked 4 | Ranked 6 | Ranked 4 | Ranked 4 | Don’t mind | I averaged out our 3 results for Opera so we end up having the same weight as any other member - and Anne and Gorm won't answer seperately. (The actual rationales are well explained, and as Bjoern said, it is really just a question of how individuals prioritise the various factors) |
| Jean-Yves Bitterlich | Ranked 5 | Don’t mind | Don’t mind | Don’t mind | Ranked 6 | Ranked 1 | - no "don't want". - Although a bit long, gE{L}BS() is preferred as it follows previous convention and also is in line with that of the Java Platform. - selectElement & matchSelector are unfavored respectively because of 1. no hints on to what to select and 2. 'match' sounds not right (subjective, see Bjoern's comment) |
| Cameron McCormack | Ranked 1 | Ranked 5 | Ranked 6 | Ranked 4 | Ranked 3 | Ranked 2 | |
| Arun Ranganathan | Ranked 2 | Ranked 4 | Ranked 6 | Ranked 3 | Don’t mind | Ranked 1 | My decision is based on intuitive developer-facing method signatures for these API calls. I voiced similar rationale in Boston. Thanks to W3C team for reminding me to fill out this poll. |
| Travis Leithead | Ranked 2 | Don’t mind | Don’t mind | Don’t mind | Don’t mind | Ranked 1 | Deep down in my heart, I believe that the getElementBy* is the most appropriate name given the DOM's naming legacy. I'm also comfortable with the name as it currently is speced and don't really mind the rest of them. I think the naming here may set a precedent for other similar "search" specs. For example, the DOM XPath L3 which uses a lot of the same design principles as the SelectorsAPI, but is currently named "evaluate" (reminds me of JavaScript's 'eval' function). |
| Ian Hickson | Don’t mind | Don’t mind | Don’t want | Don’t mind | Don’t mind | Don’t want | The inefficient one should be the longer one, and I don't think it should have more than one capital letter for the shortest method name. Apart from that I don't care. In general, I'd rather we didn't have polls and we just let the editor make decisions for such trivial bikeshedding issues as method names. I don't understand why people have made such an issue out of this. Both Anne and Lachy made good-faith decisions based on all available arguments and information and I don't understand why we haven't adopted their proposals. |
| Jim Ley | Ranked 1 | Ranked 4 | Ranked 5 | Ranked 2 | Don’t want | Don’t want | I believe my rationales have been explained before, but I will gladly expand on them again if necessary |
| Dave Raggett | Ranked 5 | Ranked 6 | Ranked 6 | Ranked 3 | Ranked 2 | Ranked 1 | The clarity of names is much more important to me than their brevity. This goes together with the aim of making code easy to understand with self explanatory names for variables and functions. This greatly helps with the inevitable maintenance that is needed for web page scripts. |
| Cedric Thienot | Ranked 2 | Ranked 5 | Ranked 6 | Ranked 4 | Ranked 3 | Ranked 1 |
More details on responses
- Lachlan Hunt: last responded on 26, July 2007 at 02:29 (UTC)
- Jonas Sicking: last responded on 26, July 2007 at 02:41 (UTC)
- Doug Schepers: last responded on 26, July 2007 at 02:47 (UTC)
- Björn Höhrmann: last responded on 26, July 2007 at 05:04 (UTC)
- Maciej Stachowiak: last responded on 26, July 2007 at 08:54 (UTC)
- Chaals Nevile: last responded on 26, July 2007 at 11:04 (UTC)
- Jean-Yves Bitterlich: last responded on 26, July 2007 at 12:22 (UTC)
- Cameron McCormack: last responded on 27, July 2007 at 09:36 (UTC)
- Arun Ranganathan: last responded on 31, July 2007 at 20:06 (UTC)
- Travis Leithead: last responded on 31, July 2007 at 21:37 (UTC)
- Ian Hickson: last responded on 1, August 2007 at 00:35 (UTC)
- Jim Ley: last responded on 1, August 2007 at 07:29 (UTC)
- Dave Raggett: last responded on 1, August 2007 at 08:40 (UTC)
- Cedric Thienot: last responded on 1, August 2007 at 09:40 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project