Re: Selectors API updates
On Jan 09, 2007, at 23:08, Anne van Kesteren wrote: I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Sorry, I don't wish to reopen the naming debate, but these really don't strike me as the ones closest to consensus (aside from being dreadful picks). I think there are a bunch of names that people don't like but can live with, these are just pure nonsense. I certainly know that while I would have dropped the ball on any number of bad options, if these stay in the draft I will request formal objection from my AC Rep. -- Robin Berjon - http://berjon.com/ In which level of metalanguage are you now speaking?
Re: Selectors API updates
I have to agree with Robin here. The new names suggested do not address the concerns raised around the original naming in the specification. Naming should be: a) descriptive of the functionality b) in line with conventions for existing DOM APIs such as getElementbyID Looking at the feedback on http://lists.w3.org/Archives/Public/public-webapi/ and Anne's blog entry at http://annevankesteren.nl/2006/12/selectors-api-naming it seems that the majority of people would agree with these principles and the suggested names based on getElementBySelector. I know not everyone is in agreement and some people wish to save keypresses but I really think we should be taking note of feedback from the majority and follow the above principles. Thanks -Dave From: Robin Berjon [EMAIL PROTECTED] Date: Wed, 10 Jan 2007 11:06:20 +0100 Message-Id: [EMAIL PROTECTED] Cc: Web API WG (public) public-webapi@w3.org To: Anne van Kesteren [EMAIL PROTECTED] On Jan 09, 2007, at 23:08, Anne van Kesteren wrote: I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Sorry, I don't wish to reopen the naming debate, but these really don't strike me as the ones closest to consensus (aside from being dreadful picks). I think there are a bunch of names that people don't like but can live with, these are just pure nonsense. I certainly know that while I would have dropped the ball on any number of bad options, if these stay in the draft I will request formal objection from my AC Rep. -- Robin Berjon - http://berjon.com/
Re: Selectors API updates
+1. The world seems to have survived with long names like getElementById() and getElementByTagname(). Dave's two reasons below are more important than brevity. Also, it is important to bear in mind that not all uses of the DOM are in the context of browsers (and CSS), so I think it is important that the method name somehow include the letters Selector or CSS. Jon Ferraiolo [EMAIL PROTECTED] Web Architect, Emerging Technologies IBM, Menlo Park, CA Mobile: +1-650-926-5865 Dave Massy [EMAIL PROTECTED] soft.com To Sent by: public-webapi@w3.org, public-webapi-req [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] cc 01/10/2007 10:14 Subject AMRe: Selectors API updates I have to agree with Robin here. The new names suggested do not address the concerns raised around the original naming in the specification. Naming should be: a) descriptive of the functionality b) in line with conventions for existing DOM APIs such as getElementbyID Looking at the feedback on http://lists.w3.org/Archives/Public/public-webapi/ and Anne's blog entry at http://annevankesteren.nl/2006/12/selectors-api-naming it seems that the majority of people would agree with these principles and the suggested names based on getElementBySelector. I know not everyone is in agreement and some people wish to save keypresses but I really think we should be taking note of feedback from the majority and follow the above principles. Thanks -Dave From: Robin Berjon [EMAIL PROTECTED] Date: Wed, 10 Jan 2007 11:06:20 +0100 Message-Id: [EMAIL PROTECTED] Cc: Web API WG (public) public-webapi@w3.org To: Anne van Kesteren [EMAIL PROTECTED] On Jan 09, 2007, at 23:08, Anne van Kesteren wrote: I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Sorry, I don't wish to reopen the naming debate, but these really don't strike me as the ones closest to consensus (aside from being dreadful picks). I think there are a bunch of names that people don't like but can live with, these are just pure nonsense. I certainly know that while I would have dropped the ball on any number of bad options, if these stay in the draft I will request formal objection from my AC Rep. -- Robin Berjon - http://berjon.com/
Re: Selectors API updates
On 1/9/07, Anne van Kesteren [EMAIL PROTECTED] wrote: These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Works for me. Thanks, Anne. -- Robert Sayre http://franklinmint.fm http://mozilla.com
Re: Selectors API updates
* Anne van Kesteren wrote: These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. As an aside, there are about 30 different get... methods on Element and/or Document nodes in DOM Core, SVG, HTML5, and your work CSS OM draft, none of which have anything to do with CSS queries. When that last issue is resolved I think the specification is ready for Last Call (again). The addition of the methods on Element objects is a substantive change and Last Calls should not include substantive changes from their previous draft. I therefore think we should publish a normal draft with these changes first. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Selectors API updates
On Wed, 10 Jan 2007 19:14:46 +0100, Dave Massy [EMAIL PROTECTED] wrote: Looking at the feedback on http://lists.w3.org/Archives/Public/public-webapi/ and Anne's blog entry at http://annevankesteren.nl/2006/12/selectors-api-naming it seems that the majority of people would agree with these principles and the suggested names based on getElementBySelector. Just to make sure I understand what majority is I took my weblog entry and counted the various names. +1 are those in favor of the proposal, 0 are those that didn't express any opinion and -1 are those against the proposal. Where proposal is the shorter name: +1 zcorpan Robert Sayre Aristotle * Henri (Anne van Kesteren) 0 Arjan Eising Daniel Morrison Blaise Simon Jessey Daniel James Richard York Chaals Christian -1 minghong Arve Laurens Holst Jaap ** Fatal Asbjørn Ulsberg * Make sure you read the whole thread. ** Jaap later switched his mind when I switched to using get() and getAll() instead in http://annevankesteren.nl/2007/01/web-api-stuff#comment-5888 So he's now +1 I suppose. Given that we're not examining that blog entry I put him in -1. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Selectors API updates
On Wed, 10 Jan 2007 20:04:29 +0100, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: When that last issue is resolved I think the specification is ready for Last Call (again). The addition of the methods on Element objects is a substantive change and Last Calls should not include substantive changes from their previous draft. I therefore think we should publish a normal draft with these changes first. I was sort of wondering about that, but didn't look it up. Thanks! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Selectors API updates
On Jan 9, 2007, at 2:08 PM, Anne van Kesteren wrote: I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. +1. I think short names will be good for readability of DOM code, if these methods become as widely used as we expect. And they will do a lot towards making standard DOM methods competitive in conciseness and ease of use with DOM Level 0 APIs. Regards, Maciej
Selectors API updates
I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Now I'm wondering whether we need Element.matchesSelector(). Basically you pass it a group of selectors and it returns true or false depending on whether or not the element would've been matched. The use case so far given is that this would make it possible to implement constructs like XBL content includes= in JavaScript. I assume there are others, but I'm wondering whether it's really worth it. When that last issue is resolved I think the specification is ready for Last Call (again). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
