[XHR] empty passwords

2007-01-26 Thread Alexey Proskuryakov
Hi! According to the current XMLHttpRequest draft, null, missing and empty password arguments to open() are treated identically - user agents must act as if the relevant data is not provided. This means that there is no way to programmatically provide an empty password. From my tests, it

Re: Selectors API naming

2007-01-26 Thread Robin Berjon
On Jan 25, 2007, at 21:18, Ian Hickson wrote: I think the mailing list is fine. However, I don't see that the current decision is any closer to the community's consensus opinion than Anne's own compromise proposal, and therefore I don't understand why the working group would override the

Re: Selectors API naming

2007-01-26 Thread Robin Berjon
On Jan 25, 2007, at 21:51, Robert Sayre wrote: I encourage you to read the WG charter. http://www.w3.org/2006/webapi/admin/charter I think Jon knows the charter :) Looking over the charter, I see the proceedings of the WG are Member-Only (bad) That is the default. Note that in January

Re: Selectors API naming

2007-01-26 Thread Simon Pieters
Hi, On Fri, 26 Jan 2007 06:26:14 +0100, João Eiras [EMAIL PROTECTED] wrote: Robert Sayre gave my permission to quote him from IRC: [20:48] sayrer wow, annevk [20:48] sayrer those names suck! [21:02] zcorpan sayrer: what names? [21:02] sayrer getElementsListBySelector [...] [21:03] *

Re: Selectors API naming

2007-01-26 Thread Robert Sayre
On 1/26/07, Robin Berjon [EMAIL PROTECTED] wrote: On Jan 25, 2007, at 21:51, Robert Sayre wrote: I encourage you to read the WG charter. http://www.w3.org/2006/webapi/admin/charter I think Jon knows the charter :) Well, I thought I would match his tone :) If the WG doesn't provide

Re: Selectors API naming

2007-01-26 Thread Robin Berjon
On Jan 26, 2007, at 19:05, Robert Sayre wrote: Well, I saw several comments from significant implementors that indicated they were unhappy with getElementsListBySelector. I don't think the WG needs to provide detailed minutes, but a list of people present at the meeting and a coherent rationale

Re: Selectors API naming

2007-01-26 Thread Charles McCathieNevile
On Fri, 26 Jan 2007 13:05:13 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Well, I saw several comments from significant implementors that indicated they were unhappy with getElementsListBySelector. I saw a handful of people saying they didn't like it. Maybe I have a different idea of what

Re: Selectors API naming

2007-01-26 Thread Robert Sayre
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2007 13:05:13 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Roughly speaking, the rationale was that nobody except Anne felt get was good, there was little support for match and strong resistance, and then we got

Re: Selectors API naming

2007-01-26 Thread Simon Pieters
Hi, On Fri, 26 Jan 2007 23:10:47 +0100, Charles McCathieNevile [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2007 06:34:28 -0500, Simon Pieters [EMAIL PROTECTED] wrote: Please note though that Robert typoed the method name. Aditionally, I typoed it too Sure. You also made a typo with

Re: Progress event spec

2007-01-26 Thread Charles McCathieNevile
On Fri, 26 Jan 2007 16:54:41 -0500, Charles McCathieNevile [EMAIL PROTECTED] wrote: Hi guys, following our face to face meeting, we are planning some changes to progress: ... Do any of these changes cause any great heartache or seem crazy? Please reply to public-webapi@w3.org - the

Re: Selectors API naming

2007-01-26 Thread Charles McCathieNevile
On Fri, 26 Jan 2007 17:33:49 -0500, Robert Sayre [EMAIL PROTECTED] wrote: On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2007 13:05:13 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Roughly speaking, the rationale was that nobody except Anne felt get was good,

Re: Progress event spec

2007-01-26 Thread Boris Zbarsky
Charles McCathieNevile wrote: 3. Add an uploadprogress It is possible to construct an XHR that is moving content up and down at the same time, so knowing when progress refers to one or the other is useful. uploadprogress is a separate event one can listen for, right? So there are

Re: Progress event spec

2007-01-26 Thread Anne van Kesteren
On Fri, 26 Jan 2007 18:10:21 -0500, Boris Zbarsky [EMAIL PROTECTED] wrote: 3. Add an uploadprogress It is possible to construct an XHR that is moving content up and down at the same time, so knowing when progress refers to one or the other is useful. uploadprogress is a separate event

Re: Selectors API naming

2007-01-26 Thread Ian Hickson
On Fri, 26 Jan 2007, Doug Schepers wrote: A way to reduce the number of typos might be to drop the trailing s from both method names. It's equally clear what it does IMHO. Hmmm... that's a reasonable point, but Selector (singular) is a bit misleading. You can provide multiple

Re: Selectors API naming

2007-01-26 Thread Robert Sayre
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: Since I have the reponsibility for getting this group to finish its work in a particular timeframe, I made a decision to find some kind of resolution in line with the process under which we are working. Which happens to offer the

Re: Selectors API naming

2007-01-26 Thread Doug Schepers
Hi, Ian- Ian Hickson wrote: On Fri, 26 Jan 2007, Doug Schepers wrote: A way to reduce the number of typos might be to drop the trailing s from both method names. It's equally clear what it does IMHO. Hmmm... that's a reasonable point, but Selector (singular) is a bit misleading. You can

Re: Progress event spec

2007-01-26 Thread João Eiras
I too have a question. If I'm downloading say 50kb, how many times will the progress event fire ? Now if I'm downloading 1MB how many times will it fire ? I doubt it'll fire every byte, else listening for this event will consume enormous amounts of cpu. I too doubt it'll fire every kilobyte,

Progress event spec

2007-01-26 Thread Charles McCathieNevile
Hi, following our face to face meeting, we are planning some changes to progress: 1. Make the total attribute 0 if the length is unknown, and drop the boolean lengthComputable. The rationale is that if you really have a zero-length load, it is unlikely to ever have time to fire a

Re: Selectors API naming

2007-01-26 Thread Simon Pieters
Hi, On Sat, 27 Jan 2007 00:12:35 +0100, Charles McCathieNevile [EMAIL PROTECTED] wrote: Of the two getElementListBySelector and getElementsBySelector, thepeople I've spoken to seem to prefer getElementsBySelector. OK. In order to make that useful feedback, can you say how many people

Re: Selectors API naming

2007-01-26 Thread Robert Sayre
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: I'm not trying to hold you up. Keep the terrible name. In the end, it is easy to route around. Indeed. This was a point raised again and again by various people. And it applies to all sides of the debate, so any claims of strong

Re: Selectors API naming

2007-01-26 Thread João Eiras
Maciej Stachowiak [EMAIL PROTECTED] escreveu: and somewhat unclear about what the method really does (sounds like Selectors would mean you give it an array of selectors or otherwise pass more than one). Excuse me, but get/getAll falls deeper in this category.

Re: Selectors API naming

2007-01-26 Thread Maciej Stachowiak
On Jan 26, 2007, at 7:14 PM, João Eiras wrote: Maciej Stachowiak [EMAIL PROTECTED] escreveu: and somewhat unclear about what the method really does (sounds like Selectors would mean you give it an array of selectors or otherwise pass more than one). Excuse me, but get/getAll falls

Re: Progress event spec

2007-01-26 Thread Boris Zbarsky
João Eiras wrote: If I'm downloading say 50kb, how many times will the progress event fire ? Now if I'm downloading 1MB how many times will it fire ? I doubt it'll fire every byte, else listening for this event will consume enormous amounts of cpu. I too doubt it'll fire every kilobyte, else

Re: Progress event spec

2007-01-26 Thread Ian Hickson
On Fri, 26 Jan 2007, Boris Zbarsky wrote: So I would hope that the spec says that not only is this implementation defined but may differ depending on the actual network connection in use I haven't actually looked at the spec, but, I would recommend something along the lines of: