[XHR] empty passwords
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 seems like this is Firefox behavior, but not IE7 one (I could successfully send requests with empty passwords without user interaction). Ability to provide empty passwords sounds like a useful bit of functionality to have. - WBR, Alexey Proskuryakov
Re: Selectors API naming
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 editor on this. Precisely. There is no consensus. That's easy to see. There wasn't going to be a consensus. Given that, it is the group's job to make an executive decision, and the editor really has no say in this, except in that s/he is part of the group. It is excessively clear to me that the WG went to great lengths to discuss this topic entirely openly with the public. This has been on the public table for over one month, with dozens of messages exchanged, and participation from both WG members and the community at large. In many cases this process has provided quality output, but on occasion, as everyone knows, it fails. And when it does, a different process is needed. You can cry out your shallow populism by talking about things taking place behind closed doors and in full opacity, it nevertheless remains that the WG did the right thing. It raises a bad precedent. If the editor is to be overriden on every little thing -- especially in cases like this, where we're moving from a set of names that a minority liked to another set of names that a different minority likes -- then we should change the editor, as it indicates that the editor is not being trusted by the working group. Quite frankly, that is total bollocks. The WebAPI has always been a strongly editor-driven. The process is normally this: an editor comes up with a draft, if there's consensus it's good, and if there isn't consensus the WG needs to make a decision (something which is usually done by asking this list for input). The size of the thing doesn't matter — otherwise there would need to be consensus on how important it is, which is endless — it's a simple matter of consensus. It certainly is not a matter of trusting the editor, no one can get consensus on everything, so whoever takes on the charge of being editor knows they'll be overruled on occasion. But of course if you actually participated in the WG as your membership allows you to instead of wasting everyone's time with uninspired drive-by comments on process, you'd know that already. (I don't think we should change the editor -- I think Anne is doing a fine job. I think the working group should let him do his job without micromanaging the names.) There is no micromanagement. No consensus means group decision, end of story. I don't think the WG needs you micromanaging its process thank you very much. -- Robin Berjon - http://berjon.com/ My whole life is waiting for the questions to which I have prepared answers. -- Tom Stoppard
Re: Selectors API naming
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 last year (i.e. at the very beginning of the group) the WG decided to perform its work in public, which they are doing. If the WG doesn't provide public minutes It used to, but it is a lot of work (since they need to be cleaned up) and people in the community rarely answer, which seems to indicate that they never read them. , and doesn't otherwise respond to public comments from WG members and the general public, This WG responds all the time, I don't know why you're saying that. I think it should change its charter to be entirely Member Confidential. I wouldn't want that, but it seems like it would be more accurate. This comes from completely nowhere. -- Robin Berjon - http://berjon.com/ I write plays because dialogue is the most respectable way of contradicting myself. -- Tom Stoppard
Re: Selectors API naming
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] * zcorpan likes get and getAll better [21:03] * sayrer notes that I got it wrong Again, this is personal taste. I could say the same for any other name. Please note though that Robert typoed the method name. Aditionally, I typoed it too when creating a poll at SitePoint Forums to see what they think: http://www.sitepoint.com/forums/showthread.php?t=454192 ...and that typo really wasn't intentional just to prove a point. It is easily typoed and I think that is a serious problem. Regards, -- Simon Pieters
Re: Selectors API naming
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 public minutes It used to, but it is a lot of work ... This WG responds all the time, I don't know why you're saying that. ... This comes from completely nowhere. 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 would do the trick. -- Robert Sayre
Re: Selectors API naming
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 would do the trick. I'm not saying that transparency can't always be improved but major implementers are participants in the working group (at the very least Opera, Apple, Microsoft, and Mozilla, not to mention folks from major mobile companies, folks that reuse browser components, and others) so presumably if the WG reached consensus they either took part in it or decided not to take part (which counts as accepting the consensus of those who do). I'm not longer on the WG so I don't know how the decision was made, but I strongly suspect that people agreed that no amount of discussion was going to get everyone to agree so they probably went for the decision that made the smallest number of people unhappy. For a naming discussion in which there is no consensus, it's unlikely that you'll get any other kind of output I'm afraid. PS: the quote at the bottom of this email was chosen at random I swear :) It's just the way of the SigMonster. -- Robin Berjon - http://berjon.com/ Interestingly enough - rendering dozens of plasticine bunnies floating in a giant vacuum cleaner complete with fake finger prints is actually easier than doing websites. Good job Microsoft and Netscape! May you rot in hell. IN HELL! -- Simon Wistow, london.pm
Re: Selectors API naming
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 significant means, but then, I could be wrong. Unfortunately for me, I am still chair and still have to try and keep the group moving forward. I don't think the WG needs to provide detailed minutes, but a list of people present at the meeting and a coherent rationale would do the trick. I spent the last couple of hours working over the minutes and just sent them to the group (and to the group we met with) for approval. You may or may not be happy with what you get - a volunteer who was observing the group was kind enough to take them, and did a reasonably good job, but not all the discussion was captured. 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 getElementBySelectors as the only obvious choice for the single element method - which everyone except Anne was happy with. In looking for a plural, getElementListBySelector was chosen becuase it was easier to distinguish than getElementsBySelector - although we are interested in feedback on that choice, and if something else clearly gets consensus we will of course change it. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: Selectors API naming
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 getElementBySelectors as the only obvious choice for the single element method - which everyone except Anne was happy with. An 's' on the end too? This is the worst name for an API I have seen in a long time, and I agree with all of Hixie's comments on the process. This is not an effective way to make changes to the Web. -- Robert Sayre http://blog.mozilla.com/rob-sayre/
Re: Selectors API naming
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 Additionally, above. Well. That was a misspelling, actually. English isn't my first language. ...and that typo really wasn't intentional just to prove a point. It is easily typoed and I think that is a serious problem. Our judgement was based on the fact that in general people who are prone to typos debug them, or use a tool to avoid making such problems. I've seen these methods be spelled incorrectly almost as often as they were spelled correctly, mostly due to wanting to type ElementsList instead of ElementList, and omitting the trailing s from Selectors. 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. Of the two getElementListBySelector and getElementsBySelector, the people I've spoken to seem to prefer getElementsBySelector. The reason for GetElementListBySelectors and not getElementsBySelectors was to make it moderately clear and give people a better chance of debugging quickly. Although if API consistency is desireable then getElementListBy... doesn't seem to appear anywhere as far as I can tell. Regards, -- Simon Pieters
Re: Progress event spec
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 public list - if you have comments. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: Selectors API naming
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, there was little support for match and strong resistance, and then wegot getElementBySelectors as the only obvious choice for the single element method - which everyone except Anne was happy with. An 's' on the end too? This is the worst name for an API I have seen in a long time, How about getElementByGroupOfSelectors (which is slightly more accurate)? and I agree with all of Hixie's comments on the process. This is not an effective way to make changes to the Web. Sitting around waiting for some magical consensus to emerge where it just clearly isn't is not an effective way to make changes either. It would be more efficient to simply wait and see what Microsoft implements. 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 opportunity to discuss with Microsoft in advance, and with various other implementors, and see if they are prepared to agree to something. Actually, I don't think the name is particularly elegant. Nor especially horrible. But if it gets the spec published, rather than indefinitely extend the last two months of having it sit around going nowhere, I can live with it. And the process that led to it which as I have said will see it happily replaced if a proposal is made that actually does show consensus). cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: Progress event spec
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 progress and uploadprogress events that implement the same interface and just refer to the different directions? -Boris
Re: Progress event spec
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 one can listen for, right? Yes. So there are progress and uploadprogress events that implement the same interface and just refer to the different directions? Yes. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Selectors API naming
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 criteria. If it helps, as one of the editors of the Selectors specification, I would say that it isn't incorrect to consider div, p to be a selector (singular). The terminology in the spec says that technically that's a group of selectors, but I wouldn't worry about that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
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 opportunity to discuss with Microsoft in advance, and with various other implementors, and see if they are prepared to agree to something. I'm not trying to hold you up. Keep the terrible name. In the end, it is easy to route around. The point on the process stands, though, and shows a awful flaw that future W3C WGs need to avoid. Perhaps this WG should be rechartered as well. The W3C process should produce standards that use idiomatic HTML, JavaScript, and CSS. That never happens. Instead, we get the typical W3C product: a result of compromise between IDE vendors, Java/C# programmers, and Semantic Web advocates. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Selectors API naming
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 provide multiple criteria. If it helps, as one of the editors of the Selectors specification, I would say that it isn't incorrect to consider div, p to be a selector (singular). The terminology in the spec says that technically that's a group of selectors, but I wouldn't worry about that. I would be fine either way. If we want to remove the s, let's do (especially if it does cause tyops). I think I was the one who suggested it to counter getElementByGroupOfSelectors (which even I think is too long). Regards- -Doug
Re: Progress event spec
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, else the previous scenario will easily apply on a fast connection. I doubt it'll fire every megabyte, else it'll be useless for slow connection or files smaller than 1mb. Please don't tell me it's implementation defined, else interoperability will be the same old headache for minoritary browser vendors. And a suggestion: in the spec I read @@Issue: Does it bubble / is it cancelable? I am not sure why it would / be, myself. It should only bubble and have as target the related document, or xhr object, just like the load event. Charles McCathieNevile [EMAIL PROTECTED] escreveu: 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 progress event, and will almost certainly only fire any in a really degenerate case. Having a large number was a bad idea, since one day you will have a large number of bytes, and having anegative number meant having a signed instead of unsigned integer. 2. Remove the preload and postload events. You know when it finished, because the load event or whatever is spitting out progress will have finished. You know when it started, because you got a progress event. 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. 4. Rename loadprogress to progress It's shorter. Do any of these changes cause any great heartache or seem crazy? I haven't updated the draft at http://dev.w3.org/cvsweb/2006/webapi/progress/ yet but I will try to do that ASAP so we can request first public working draft. cheers Chaals
Progress event spec
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 progress event, and will almost certainly only fire any in a really degenerate case. Having a large number was a bad idea, since one day you will have a large number of bytes, and having anegative number meant having a signed instead of unsigned integer. 2. Remove the preload and postload events. You know when it finished, because the load event or whatever is spitting out progress will have finished. You know when it started, because you got a progress event. 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. 4. Rename loadprogress to progress It's shorter. Do any of these changes cause any great heartache or seem crazy? I haven't updated the draft at http://dev.w3.org/cvsweb/2006/webapi/progress/ yet but I will try to do that ASAP so we can request first public working draft. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: Selectors API naming
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 and who they are? With comments like this, it is hard to know if you are one of five people all saying the same thing as they talk to each other, or someone representing some process that had 3% of professional Web Developers in Russia who decided to take a binding vote on their preferred outcome... Sure. At the time of writing, the poll[1] I started has 4 votes on getElementsBySelector and 0 votes on getElementListBySelector (and 1 vote on each of the short names). On IM the other day, Ben 'Cerbera' Millard said: getElementBySelector(), getElementsBySelector() - seem the most sensible to me kinda consitant with DOM naming I've probably forgot some other guy, however so far I haven't heard anyone prefer getElementListBySelector. [1] http://www.sitepoint.com/forums/showthread.php?t=454192 Regards, -- Simon Pieters
Re: Selectors API naming
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 resistance are bogus. Should have stuck with the editor's initial choice and saved WG time. Feel free to propose a new W3C process of some kind, but that isn't actually the concern of this working group, which has certain tasks to do under an existing set of conditions. You should take them up with the right part of W3C if you want to have an effective conversation. If you want to create effective specifications, the way to respond to harsh technical and ethical criticism is not to dismiss it by pointing out that you are following the correct bureaucratic procedure. -- Robert Sayre
Re: Selectors API naming
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
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 deeper in this category. Those were not my favorite names either, but they do at least meet the requirement of concise. Regards, Maciej
Re: Progress event spec
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 the previous scenario will easily apply on a fast connection. I doubt it'll fire every megabyte, else it'll be useless for slow connection or files smaller than 1mb. Please don't tell me it's implementation defined, else interoperability will be the same old headache for minoritary browser vendors. I would hope it depends on how fast the data arrives, with the event firing as it comes in. Which depends on the connection speed, HTTP packet sizes, etc. If data is sent in 5KB packets, the event can't fire more often than once every 5KB, no? 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 Given that even a single UA couldn't really guarantee anything here (see above), I doubt anyone will ever seriously depend on the exact number of times this fires. That said, people _might_ depend on it actually firing once data comes in (e.g. to provide a useful progressmeter), but even then, if you get all the data in a single (possibly huge) packet, there's not much you can do. And the UA has no control over that. -Boris P.S. The above opinions are my own; I represent no one here.
Re: Progress event spec
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: MUST fire at zero bytes MUST fire again at the end, even if that is zero bytes SHOULD fire at least once every 500ms in between the above two events, unless no progress has been made in that time. SHOULD NOT fire more than once every 10ms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
