Re: Selectors API naming

Na , Simon Pieters <[EMAIL PROTECTED]> escreveu: Hi, On Thu, 25 Jan 2007 19:26:38 +0100, Anne van Kesteren <[EMAIL PROTECTED]> wrote: So the WG just discussed in a little over an hour a counter proposal to the current naming[1] and came up with: * getElementBySelectors() * getElementL

Re: Selectors API naming

Hi, On Thu, 25 Jan 2007 19:26:38 +0100, Anne van Kesteren <[EMAIL PROTECTED]> wrote: So the WG just discussed in a little over an hour a counter proposal to the current naming[1] and came up with: * getElementBySelectors() * getElementListBySelectors() I like get() and getAll() much be

Re: Fwd: minor clarifications to ProgressEvent

On Thu, 25 Jan 2007 10:11:52 -0500, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: * Charles McCathieNevile wrote: For the namespaceURI parameter to initProgressEventNS (actually, to all the initXXXEventNS methods): is it legal for this parameter to be null? I think this needs to be clarified:

Re: Editorial Control

Hi, Ian- Ian Hickson wrote: As you say, the WG here just moved from one minority opinion to another minority opinion. So this isn't a case where Anne's decision was not representative of the wider community. You're implying with the term "minority opinion" that there was a "majority opini

Re: Editorial Control (was: Selectors API naming)

On Thu, 25 Jan 2007, Doug Schepers wrote: > > [...] I made exactly the point that you did -- you should have an editor who makes decisions, but can be overriden by a working group when the decisions are not representative of the community. As you say, the WG here just moved from one minority o

Editorial Control (was: Selectors API naming)

Ian Hickson wrote: On Thu, 25 Jan 2007, João Eiras wrote: So, it's a matter of personal opinion that "names suck". My argument is not that the names suck. My argument is that there is not concensus, that the decision process was opaque and behind-closed-doors, The discussion was not done

Re: Selectors API naming

On 1/25/07, Jon Ferraiolo <[EMAIL PROTECTED]> wrote: I encourage you to read the process document I encourage you to read the WG charter. Looking over the charter, I see the proceedings of the WG are Member-Only (bad), but it also states: "For e

Re: Selectors API naming

Ian, While I agree that the W3C should change as the world changes within it, process changes at W3C aren't something that occur just because you or I have a particular opinion about what process changes should occur. I encourage you to read the process document, particularly the section about how

Re: Selectors API naming

On Thu, 25 Jan 2007, Nicolas Mendoza wrote: > > I suppose you agree though, that after discussing something in the open > (Hey, even I was able to comment on the naming scheme. My voice was > heard, without being member of any w3c group.) someone needs to take a > decision. It seems natural th

Re: Selectors API naming

On Thu, 25 Jan 2007 20:43:50 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote: ... Web specifications affect everyone in the Web community, and so Web specifications should be developed in the open. The term "Working Group Member" is misleading -- there should not be anything special to being a W

Re: [selectors api] Why two methods?

On 2007-01-25 20:53, Anne van Kesteren wrote: On Thu, 25 Jan 2007 14:48:35 -0500, David Håsäther <[EMAIL PROTECTED]> wrote: What I mean is, why does grabbing the first node deserve its own method? Is that really a common thing to do, grabbing the first node? More common than grabbing the secon

Re: [selectors api] Why two methods?

On Thu, 25 Jan 2007 14:48:35 -0500, David Håsäther <[EMAIL PROTECTED]> wrote: Why does the Selectors API define two methods for retrieving nodes? I understand that there are speed gains by having a method that grabs just the first node, but how often do you want to do that? Don't you want to

Re: [selectors api] Why two methods?

"David Håsäther" <[EMAIL PROTECTED]> On 2007-01-25 20:42, Anne van Kesteren wrote: On Thu, 25 Jan 2007 14:39:46 -0500, David Håsäther <[EMAIL PROTECTED]> wrote: Why does the Selectors API define two methods for retrieving nodes? I understand that there are speed gains by having a method that

Re: [selectors api] Why two methods?

On 2007-01-25 20:42, Anne van Kesteren wrote: On Thu, 25 Jan 2007 14:39:46 -0500, David Håsäther <[EMAIL PROTECTED]> wrote: Why does the Selectors API define two methods for retrieving nodes? I understand that there are speed gains by having a method that grabs just the first node, but how oft

Re: Selectors API naming

On Thu, 25 Jan 2007, Jon Ferraiolo wrote: > > Editors are in charge of the words in a spec and simply make sure that > the will of the WG is reflected in the spec. I don't understand where > there is bad precedent in this. While this has indeed been the way that the W3C has developed specifica

Re: [selectors api] Why two methods?

On Thu, 25 Jan 2007 14:39:46 -0500, David Håsäther <[EMAIL PROTECTED]> wrote: Why does the Selectors API define two methods for retrieving nodes? I understand that there are speed gains by having a method that grabs just the first node, but how often do you want to do that? Don't you want to

[selectors api] Why two methods?

Why does the Selectors API define two methods for retrieving nodes? I understand that there are speed gains by having a method that grabs just the first node, but how often do you want to do that? Don't you want to grab the second node as often? Or the last? -- David Håsäther

Re: Selectors API naming

Ian, Editors are in charge of the words in a spec and simply make sure that the will of the WG is reflected in the spec. I don't understand where there is bad precedent in this. On the other hand, it would be very bad precedent if editors attempted to override the will of the WG to make specs refl

Re: Selectors API naming

On Thu, 25 Jan 2007, João Eiras wrote: > > > > Given that this discussion was done behind closed doors, and given > > that there is certainly not consensus on this (the first reaction I > > saw on IRC to this was "wow, those names suck!") > > I find these much better than all other propositions

Re: Selectors API naming

Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: On Thu, 25 Jan 2007, Anne van Kesteren wrote: So the WG just discussed in a little over an hour a counter proposal to the current naming[1] and came up with: * getElementBySelectors() * getElementListBySelectors() I don't really like them. S

Re: Selectors API naming

On Thu, 25 Jan 2007, Anne van Kesteren wrote: > > So the WG just discussed in a little over an hour a counter proposal to > the current naming[1] and came up with: > > * getElementBySelectors() > * getElementListBySelectors() > > I don't really like them. Supposedly I'm to edit the draft to

Re: Selectors API naming

Hi Anne, These names are fine with me. Jon ps - I can certainly sympathize with you having to make an editorial change with which you disagree. I had to do this hundreds of time during my editorial stints in W3C committees. The worst one of all was when the SVG working decided against my very st

Selectors API naming

So the WG just discussed in a little over an hour a counter proposal to the current naming[1] and came up with: * getElementBySelectors() * getElementListBySelectors() I don't really like them. Supposedly I'm to edit the draft to reflect this... [1]

Re: Fwd: minor clarifications to ProgressEvent

* Charles McCathieNevile wrote: >For the namespaceURI parameter to initProgressEventNS (actually, to all >the initXXXEventNS methods): is it legal for this parameter to be null? >I think this needs to be clarified: is there an expectation that if the >namespace is null the non-NS init method shoul

Fwd: minor clarifications to ProgressEvent

--- Forwarded message --- From: "Ellen Siegel" <[EMAIL PROTECTED]> To: "Nandini Ramani" <[EMAIL PROTECTED]>, "Charles McCathieNevile" <[EMAIL PROTECTED]> Cc: "Vincent Hardy" <[EMAIL PROTECTED]> Subject: minor clarifications to ProgressEvent Date: Wed, 03 Jan 2007 17:41:06 -0500 Char