Re: Selectors API naming

On 12/19/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > 2. Naming > getElementBySelector/getElementsBySelector is the only proposal we think > is acceptable. But it's not accurate. This also creates the problem Ian Hickson pointed out a few times. That people will map it to $$ or something

Re: Selectors API naming

On Dec 19, 2006, at 21:50, Anne van Kesteren wrote: On Tue, 19 Dec 2006 21:35:17 +0100, Dave Massy <[EMAIL PROTECTED]> wrote: 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

Re: Selectors API naming

On Dec 19, 2006, at 17:51, Charles McCathieNevile wrote: 1. Does anyone see any other issue in the current draft that should be fixed? 2. For the following options, do you consider the names "fine", "not great but acceptable", or "unacceptable"? getElementBySelector/getElementsBySelecto

Re: Selectors API naming

If you want to be accurate, the methods should be named getElementByCSSSelector getElementsByCSSSelector and be integrated with the CSS DOM module. There's one thing I don't understand ? Why returning a StaticNodelist ? if I want something static I just use some xpath to get a snapshot. CSS se

Re: Selectors API naming

On Wed, 20 Dec 2006 14:45:56 +0100, Joao Eiras <[EMAIL PROTECTED]> wrote: If you want to be accurate, the methods should be named getElementByCSSSelector getElementsByCSSSelector and be integrated with the CSS DOM module. No, the Selectors specification is separate from CSS. Accurate and

Re: Selectors API naming

On Dec 20, 2006, at 14:51, Anne van Kesteren wrote: No, the Selectors specification is separate from CSS. That belief only exists within the small ivory tower known as "The CSS Working Group". To those of us who actually use the stuff for work, that distinction is a totally moot political

Re: Selectors API naming

On Wed, 20 Dec 2006 15:02:47 +0100, Robin Berjon <[EMAIL PROTECTED]> wrote: On Dec 20, 2006, at 14:51, Anne van Kesteren wrote: No, the Selectors specification is separate from CSS. That belief only exists within the small ivory tower known as "The CSS Working Group". To those of us who act

Re: Selectors API naming

On Dec 20, 2006, at 15:20, Anne van Kesteren wrote: On Wed, 20 Dec 2006 15:02:47 +0100, Robin Berjon <[EMAIL PROTECTED]> wrote: On Dec 20, 2006, at 14:51, Anne van Kesteren wrote: No, the Selectors specification is separate from CSS. That belief only exists within the small ivory tower know

RE: Selectors API naming

This is actually in reply to a number of people. Ian Hickson [mailto:[EMAIL PROTECTED] wrote: >[Chris Wilson wrote] >> and that makes the APIs feel like they were designed together. > >Sure... But we have to learn from the lessons we were taught by DOM and >the way that authors are writing code

Re: Selectors API naming

On Tue, 19 Dec 2006 17:51:37 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: 1. Does anyone see any other issue in the current draft that should be fixed? I'm happy... 2. For the following options, do you consider the names "fine", "not great but acceptable", or "unacceptable"

Re: Selectors API naming

On Wed, 20 Dec 2006 18:55:42 +0100, Chris Wilson <[EMAIL PROTECTED]> wrote: Anne van Kesteren [mailto:[EMAIL PROTECTED] wrote: [Dave Massy wrote:] As I mentioned previously a more complete example of staticNodeList usage would also be appreciated. It's not clear to me what you mean with th

Re: Selectors API naming

"Chris Wilson" <[EMAIL PROTECTED]> Not that I'm overly energised with naming, but... As Martijn said, I believe people will map document.matchAll almost as often to $$ as document.getElementsBySelector - so I'd much rather stick with the pattern, and presume that if developers want to map to a

Re: Selectors API naming

On 12/20/06, Jim Ley <[EMAIL PROTECTED]> wrote: Not that I'm overly energised with naming, but... ... I agree with this view entirely. getSomething is a pattern worth keeping for developer sanity. JS programmers use short names for these things. Like $() instead of getElementById. The name

Re: Selectors API naming

"Robert Sayre" <[EMAIL PROTECTED]> On 12/20/06, Jim Ley <[EMAIL PROTECTED]> wrote: Not that I'm overly energised with naming, but... ... I agree with this view entirely. getSomething is a pattern worth keeping for developer sanity. JS programmers use short names for these things. Like $()

Re: Selectors API naming

On Wed, 20 Dec 2006 19:13:08 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: On Tue, 19 Dec 2006 17:51:37 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: 1. Does anyone see any other issue in the current draft that should be fixed? I'm happy... 2. For the followin

Re: Selectors API naming

On 12/20/06, Jim Ley <[EMAIL PROTECTED]> wrote: No, one group of JS programmers do that, it is not representative of the entire industry at all Mappings to getElementById in some popular JS libraries: Yahoo UI: get() Prototype.js: $() MochiKit: $() dojo: byId() etc, etc. I guess that's the

Re: Selectors API naming

On 12/20/06, Robert Sayre <[EMAIL PROTECTED]> wrote: On 12/20/06, Jim Ley <[EMAIL PROTECTED]> wrote: > > No, one group of JS programmers do that, it is not representative of the > entire industry at all Mappings to getElementById in some popular JS libraries: Yahoo UI: get() Prototype.js: $()

Re: Selectors API naming

On 12/20/06, Martijn <[EMAIL PROTECTED]> wrote: So would thes popular JS libraries stop using those names if document.getElementById was called document.id for example? Who can say? It seems to me they wouldn't as it would still be too long for their taste (the maximum length in these examp

RE: Selectors API naming

The DOM L3 XPath specification is a Note, not a Recommendation. I would expect to have the same discussion about minimalism and polluting the document object if it were to be Proposed. -Original Message- From: Robert Sayre [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 11:

Re: Selectors API naming

On 12/20/06, Chris Wilson <[EMAIL PROTECTED]> wrote: The DOM L3 XPath specification is a Note, not a Recommendation. That's right. I haven't heard of any technical problems with that standard's document.evaluate method name. I would expect to have the same discussion about minimalism and L

Re: Selectors API naming

As do I. Descriptive names are useful. Regards- -Doug Jon Ferraiolo wrote: I agree with the Microsoft folks on this thread. Jon Jon Ferraiolo <[EMAIL PROTECTED]> Web Architect, Emerging Technologies IBM, Menlo Park, CA Mobile: +1-650-926-5865

Re: Selectors API naming

This thread is going nowhere. I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. There's no point us arguing over names, we'd only end up with a spec full of compromises a

Re: Selectors API naming

On 12/20/06, Robert Sayre <[EMAIL PROTECTED]> wrote: On 12/20/06, Martijn <[EMAIL PROTECTED]> wrote: > > So would thes popular JS libraries stop using those names if > document.getElementById was called document.id for example? Who can say? I can't say, but I don't think they would stop. >

Re: Selectors API naming

Hi Robert, FWIW - Dojo's function is actually [window.]dojo.byId() and I believe that Yahoo's is [window.]YAHOO.util.get(). Jon Jon Ferraiolo <[EMAIL PROTECTED]> Web Architect, Emerging Technologies IBM, Menlo Park, CA Mobile: +1-650-926-5865

Re: Selectors API naming

On Dec 20, 2006, at 23:02, Ian Hickson wrote: This thread is going nowhere. I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. There's no point us arguing over names, we

Re: Selectors API naming

Hi- Ian Hickson wrote: > > This thread is going nowhere. I propose that we let the document's > editor take into account all the input and then have the editor make a > decision that addresses everyone's concerns as much as possible. I agree that most of the useful arguments have been made. St

Re: Selectors API naming

On Wed, 20 Dec 2006, Robin Berjon wrote: > On Dec 20, 2006, at 23:02, Ian Hickson wrote: > > > > This thread is going nowhere. I propose that we let the document's > > editor take into account all the input and then have the editor make a > > decision that addresses everyone's concerns as much a

Re: Selectors API naming

On Wed, 20 Dec 2006 23:25:34 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote: I agree that most of the useful arguments have been made. Stripping away the arguments themselves, there are only 3 stances: 1) Shorter names are preferred; 2) More descriptive names are preferred; 3) Names matchi

Re: Selectors API naming

Hi- Ian Hickson wrote: There's no point us arguing over names, we'd only end up with a spec full of compromises and smelling of design-by-committee. This statement sounds like compromise and considering multiple viewpoints are bad things. I strongly disagree. An optimal design is not n

Re: Selectors API naming

On Wed, 20 Dec 2006, Doug Schepers wrote: > > Ian Hickson wrote: > > > > There's no point us arguing over names, we'd only end up with a spec > > full of compromises and smelling of design-by-committee. > > This statement sounds like compromise and considering multiple > viewpoints are bad thi

Re: Selectors API naming

Hi- Some context... Ian Hickson wrote: I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. [...] I have confidence in Anne; I'm sure he would not design by theology,

Re: Selectors API naming

On Wed, 20 Dec 2006 23:46:08 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote: One of the arguments that was made was also that the existing methods have failed, which would make #3 the odd one out and probably #2 as well. "I don't really care what the final name, but it should match the first pri

Re: Selectors API naming

On 12/20/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote: One of the arguments that was made was also that the existing methods have failed, which would make #3 the odd one out and probably #2 as well. "I don't really care what the final name, but it should match the first principle..." I don

Re: Selectors API naming

On Wed, 20 Dec 2006, Doug Schepers wrote: > > Given the editor's strong stance for your own viewpoint, it seems that > your deference to him is not altruistic. This is the only item that's been heavily argued on the mailing list. I'd be saying the same thing if Anne had suggested the opposite.

Re: Selectors API naming

Hi- Anne van Kesteren wrote: On Wed, 20 Dec 2006 23:46:08 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote: One of the arguments that was made was also that the existing methods have failed, which would make #3 the odd one out and probably #2 as well. "I don't really care what the final name, b

Re: Selectors API naming

Jon Ferraiolo <[EMAIL PROTECTED]> wrote: FWIW - Dojo's function is actually [window.]dojo.byId() and I believe that Yahoo's is [window.]YAHOO.util.get() Yes, those are the canonical locations. They are usually copied around. But we arguing about the right side of the last period anyway. On 1

Re: Selectors API naming

On Thu, 21 Dec 2006 00:59:04 +0100, Robert Sayre <[EMAIL PROTECTED]> wrote: ... Ian Hickson wrote: In my experience with cat fighting on mailing lists, what you'll end up having is whoever gave up last wins. This is more a test of who has the most free time, not a test of who has the stro

RE: Selectors API naming

? I never claimed there were technical problems with "matchAll" or "select" either - just that they didn't fit the pattern established by the other DOM Recommendation APIs, and therefore weren't the best choice for an API that was supposed to fit in the larger scope of the web object model platfo

Re: Selectors API naming

On 12/20/06, Chris Wilson <[EMAIL PROTECTED]> wrote: ? I never claimed there were technical problems with "matchAll" or "select" either - just that they didn't fit the pattern established by the other DOM Recommendation APIs, Web authors don't encounter a consistent pattern, and what is and i

RE: Selectors API naming

Robert Sayre [mailto:[EMAIL PROTECTED] wrote: >On 12/20/06, Chris Wilson <[EMAIL PROTECTED]> wrote: >> ? I never claimed there were technical problems with "matchAll" or >> "select" either - just that they didn't fit the pattern established by >> the other DOM Recommendation APIs, > >Web authors

Re: Selectors API naming

I know it's kind of late in the game to be discussing this, but I prefer getElementBySelector(), simply because it matches what has come before. In all seriousness, you'll hear people complain about having to use select as the function name, claiming that is too long. If people want shorter n

Re: Selectors API naming

Hi- I agree. I think "getElementsBySelector()" is a good name that follows a meaningful naming convention. Having a slightly longer name for a method doesn't prevent people from making shorter aliases, but having an unclear name does prevent people from understanding it intuitively. Rega

Re: Selectors API naming

On 12/20/06, Chris Wilson <[EMAIL PROTECTED]> wrote: I disagree. Anyone who uses both getElementsByTagName and getElementByID encounters a pattern. They do not encounter a pattern of return values, allowed arguments, handling of strange arguments (e.g. document.getElementById(null)), or erro

Re: Selectors API naming

Hi- Robert Sayre wrote: On 12/20/06, Doug Schepers <[EMAIL PROTECTED]> wrote: That those methods have "failed" is not conclusive. Well, the possibility has certainly been widely discussed. Huh? The first 2 pages (at least) of that search seemed

Re: Selectors API naming

On 12/20/06, Doug Schepers <[EMAIL PROTECTED]> wrote: Huh? The first 2 pages (at least) of that search seemed to complain about the lack of consistency in support among different browsers, not about the supposed "failure" of the longer DOM method names. [1] Can't say it much better than "DO

Re: Selectors API naming

Hi, Robert- Robert Sayre wrote: On 12/20/06, Doug Schepers <[EMAIL PROTECTED]> wrote: Huh? The first 2 pages (at least) of that search seemed to complain about the lack of consistency in support among different browsers, not about the supposed "failure" of the longer DOM method names. [1]

Re: Selectors API naming

On Wednesday, December 20, 2006 10:25 pm, Doug Schepers wrote: > Hi, Robert- > > I think that the substance of that critique is about the functionality > and the implementation (memory and speed) footprint of DOM. I just dropped a comment on that discussion, because to be frank it's one of the s