Re: [Progress events] There is no way to create progress events using document.createEvent
On Thu, 05 Jun 2008 17:50:46 +0200, Olli Pettay <[EMAIL PROTECTED]> wrote: Hi all, PE seems to miss the eventType string for progress events so that document.createEvent could be used to create such events. The eventType string should be "ProgressEvent" This seems to make sense to me. I raised ISSUE-3 to remind me (since it requires thinking, right now is not when I will figure it out) Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Progress Events
On Fri, 23 May 2008 18:25:36 +0200, Olli Pettay <[EMAIL PROTECTED]> wrote: Hi all, Because the user agent must support DOM events, the following text could be removed: "User agents must ensure that these events trigger event listeners attached on Element nodes for that event and on the capture and target phases." That text is anyway a bit strange, especially when progress events are used with XHR. The text is a bit strange. It was added in response to Ian's mail saying he had difficuly understanding which requirements applied to which implementations, as part of the attempt to provide more explicit requirements. There is no formal requirement in the current draft that user agents implement DOM events - but perhaps that would be a simpler way of setting the requirement? And it would be great to mark chapters to be either normative or non-normative. And numbering the chapters would be great too. I agree, and will do both of these for or before the next public draft. cheers and thanks for the comments Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [progress-events] loaded member misnamed?
Reply-to set to webapps - note we are in a transition... On Wed, 28 May 2008 13:01:13 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: Hi, Yesterday someone contacted me on IRC about implementing XMLHttpRequest.upload from XMLHttpRequest Level 2. It turns out that the Progress Events specification is not generic enough for both uploading and downloading as we agreed it should be long ago. The ProgressEvent.loaded member should probably be defined in a more abstract way Can you explain in more detail what should be changed? (Feel free to raise a new issue for this in the webapps tracker - otherwise I will when I understasnd a bit more clearly what the issue is about). and I would actually suggest to rename it to ProgressEvent.transferred so it's clear that it is about transferred data. Probably, but like many things we inherited a name and there are existing implementations using it, so it seemed sensible to keep the names stable. This is issue 119 [1] in the webapi tracker [1] http://www.w3.org/2006/webapi/track/issues/119 cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [progress-events]Some comments
On Thu, 29 May 2008 13:10:50 +0200, Olli Pettay <[EMAIL PROTECTED]> wrote: Hi all, some more comments: (1) "typeArg of type DOMString This must be one of loadstart, progress, error, abort, load. If it is not one of those values then this specification does not define the resulting event..." I'd reword that somehow and definitely remove the "must be" part, since the type doesn't have to be one of those event types. Agreed. I changed the wording in my local draft (so will appear in the next editor's draft shortly) (2) "canBubbleArg of type boolean Specifies Event.bubbles. This parameter overrides the intrinsic bubbling behavior of the event and determines whether the event created will bubble cancelableArg of type boolean Specifies Event.cancelable. This parameter overrides the intrinsic cancel behavior of the event and determines whether the event created is cancelable" I know that is copied from DOM 3 Events draft, but 'intrinsic bubbling behavior' and 'intrinsic cancel behavior' aren't actually defined anywhere. Perhaps should modify that in DOM 3 Events. That makes sense to me (plus it means I don't need to do anything new ;) Sentences should end to a . Changed for the cases noted. (3) "If the user agent has reliable information about the value of total, then this should be true. If the user agent does not have reliable information about the vale of total, this should be false" vale -> value and . after false Done. (4) Missing "informative" for example in chapter 'Using progress events in Web content' Done Other comments http://lists.w3.org/Archives/Public/public-webapi/2008May/0349.html http://lists.w3.org/Archives/Public/public-webapi/2008May/0478.html Yep. Thanks for the various comments, by the way. It's nice to have the feedback ;) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Geolocation ideas
On Thu, 05 Jun 2008 22:09:30 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote: Matt Womer set up a (temporary?) playground to submit geolocation API documents for discussion: http://dev.w3.org/geo/ and http://dev.w3.org/geo/api All of Chaals' caveats above apply to the new repo, too, of course... as do any IPR issues you can think of. And any documents can be sent to the public-geolocation email list as attachments, too, if that is more convenient. Although there is a W3C policy on what kind of attachments are acceptable. In short, please use HTML if you have to do this. (Having versioned documents is far better than attachments IMHO) Well, the reply gets out according to the vagaries of net access and my time, which is the same rule that always applies. You just picked the moment I finished work and went to celebrate my birthday as the time to send mail, which was perhaps an unluckily sub-optimal choice. Happy birthday! Thanks ;) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Geolocation ideas
On Thu, 05 Jun 2008 23:01:28 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote: On Thu, 5 Jun 2008, Charles McCathieNevile wrote: > > Could you please confirm that it is acceptable for us to begin > unofficially discussing geolocation API requirements on the > public-webapi@w3.org mailing list and for us to start noodling on > ideas in CVS in the http://dev.w3.org/cvsweb/2006/webapi/ directory? > We would like to start today. I cannot stop you doing it. On the other hand, given that there is an existing mailing list and that you have been explicitly asked to use it for the topic it was set up for, it seems a bit small-minded not to do so. Okie dokie. We'll use the public-geolocation list. Happy birthday, btw. :-) Thanks and thanks :) cheers Chaals-the-slightly-more-connected On Thu, 5 Jun 2008, Doug Schepers wrote: Matt Womer set up a (temporary?) playground to submit geolocation API documents for discussion: http://dev.w3.org/geo/ and http://dev.w3.org/geo/api Cool, we'll use that. Cheers, -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Geolocation ideas
Cc+ appformats, since it seems that we will be merged with them soon and they should get a chance to comment too (although there is a large overlap I don't think it is 100%). On Tue, 03 Jun 2008 17:33:53 -0300, Ian Hickson <[EMAIL PROTECTED]> wrote: Hey Chaals, Could you please confirm that it is acceptable for us to begin unofficially discussing geolocation API requirements on the public-webapi@w3.org mailing list and for us to start noodling on ideas in CVS in the http://dev.w3.org/cvsweb/2006/webapi/ directory? We would like to start today. I cannot stop you doing it. On the other hand, given that there is an existing mailing list and that you have been explicitly asked to use it for the topic it was set up for, it seems a bit small-minded not to do so. Is there any obvious reason for continuing the discussion here that has escaped my attention? I am concerned about the effect one can observe in HTML, where effective transparency is destroyed by the fact that there are an large set of different discussion fora one needs to track in order to discover where relevant information is, making it very difficult to determine what is being proposed, let aone decided, unless one works full-time on HTML. I don't see that as conducive to good, informed open development. I would therefore request that you keep discussion on this topic to the mailing list designed to gather it in one place. If yes, then could you maybe please also confirm that the working group will adopt geolocation APIs as a working group work item, at least until the W3C has decided whether to create a new working group for this? As far as I can tell no working group members has expressed their dissent and several have expressed their agreement since I first mentioned this last week, which puts us ahead of most of our working group decisions! :-) It would appear that someone is sitting on some kind of IPR/patent block that has been commnicated to hte team in confidence. So there is nnot much we can do to figure out who or what except look at the ongoing communication and see if something stands out enough to start making speculative guesses. Unfortunately, this is not easy to work with. Formally taking on the work item in this group within this context seems like a bad idea - the patent policy is there for a reason and we don't do ourselves a lot of favours by pretending that the world is nicer than it is. Like you, I am upset that W3C has decided to split this off somewhere else, and that in the best case we will have to wait weeks to do anything formal (and for possible worst cases we can consider the 6 months it took to propose a charter we had pretty much agreed on as a strawman, or the years that some W3C activities have gone without charters :( ). However, unless there is no sign of progress in W3C (and at the moment they are showing signs of progress, if not actual measurable reaching of the various milestones for a new group) I propose to defer the question, rather than try to take on a new formal deliverable. If there is no apparent movement in the time between now and our face to face meeting, that may be time to take it up again. In the meantime why not give the W3C Team a little credit for acting in good faith, and the time to do their work at a reasonable rate? Since the webspace at dev.w3.org/2006/webapi is just a set of addresses for convenience, and since we are discussing something that is clearly some kind of WebAPI, unless there is some process reason I don't know of or you do something blatantly stupid like trying to make a document look like it has more W3C support than it does through inappropriate use of stylesheets, missing or misleading status statements and so on, I don't see that it is impossible to put a proposal for a spec into that space. Indeed, there is no reason I can see that a geolocation group could not continue using a chunk of that space, given that there is trust between the members of the two groups not to step on each other's work. I understand that you are travelling; my apologies for making this request when you are indisposed. Well, the reply gets out according to the vagaries of net access and my time, which is the same rule that always applies. You just picked the moment I finished work and went to celebrate my birthday as the time to send mail, which was perhaps an unluckily sub-optimal choice. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: XHR review extension
On Tue, 03 Jun 2008 11:12:21 -0300, Doug Schepers <[EMAIL PROTECTED]> wrote: Hi, Anne- Anne van Kesteren wrote (on 6/3/08 9:44 AM): On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom <[EMAIL PROTECTED]> wrote: The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. Actually, it is a process issue... I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. The urgency is based on the fact that people are looking to implement, or update implementations, in part because this spec is an important base for XHR2. We have an upcoming face to face meeting beginning 1 July, where we plan to close any final issues. Microsoft's review has already taken a long time, and has been promised within the week. However I note the request in private for an extension received a week or so ago. Therefore, If the SVG group can please try to produce its review as fast as possible, we can grant the requested extension to 16 June. Please note that we will not be giving a further extension without clear explanation of the exceptional circumstances that should justify it, and we would appreciate every day before then which you can reach. (We would also have appreciated the request coming in well before the deadline, ideally with some explanation...) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ElementTraversal progress?
On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote: Hi WebAPI fans! WebAPI! WebAPI! WebAPI! (Sorry) I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. It would be great to have this resolved pretty soon. The development cycle for our next release is quite short so if we want to add ElementTraversal to the release we would ideally like to see it more stable pretty soon. As before I'm still of the opinion that a .childElements NodeList would be a better solution. While I agree that it can be more complex to implement, I still think that the value vs. cost ratio still is quite good. One of the issues involved in a new, more complicated solution is precisely the one of stabilising the spec relatively quickly. Personally I think it seems better to go with what we have right now, and look at adding more in a seperate piece of work, so as to stabilise and finish the spec... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Proposal to work on Geolocation
On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On May 27, 2008, at 2:01 PM, Doug Schepers wrote: ... In fact, I proposed on the WebApps WG charter to add this deliverable. However, the Advisory Committee's review of the charter indicated that the Membership wants this to happen in a dedicated Geolocation API WG. The W3C intends to follow through on that, and to allocate Team resources to this valuable technology. We will announce something formal soon. ... I could not find record of any such objection in the Advisory Committee mailing list archives, or any record of an official W3C decision on this point. As Team contact, could you please explain who made this decision and on what basis? In which case I presume that someone used their ability to reply to the Team privately instead of being open about what they wanted. This disturbs me a little since it increases the resources and coordination required, IMHO, to do what is a pretty simple piece of work. For the record, Opera would also like to see the geolocation work take place inside the webAPI group and is unhappy that it has been removed from the proposed charter for Web Apps. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: File IO...
On Wed, 07 May 2008 15:39:01 +0200, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: Opera has a proposal for a specification that would revive (and supersede) the file upload API that has been lingering so long as a work item. ... A draft is at http://dev.w3.org/2006/webapi/fileio/fileIO.htm so you can have a look. As promised a while ago, we have made some experimental builds, which enable this in widgets, to play around with. There is some documentation at http://dev.opera.com/libraries/fileio/ with some code examples at http://dev.opera.com/libraries/fileio/FileIO-examples.zip The builds that run this are available in a bunch of different flavours. Windows: http://snapshot.opera.com/windows/o950s_io_9974.exe Mac OS X: http://snapshot.opera.com/mac/o950s_io_4810.dmg (may require at least OS X.3) Linux: Assorted intel and x86 64bit packages are linked from http://snapshot.opera.com/unix/snapshot_io-1952/ These are experimental builds. No Warranty for any purpose implied. Handle with care. Anyway, hopefully this allows people to have a play with the ideas, and see where the interesting stuff leads. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Proposal for Cross Site Requests
On Mon, 12 May 2008 18:43:51 +0200, Jon Ferraiolo <[EMAIL PROTECTED]> wrote: Hi Chris, Just to be clear, OpenAjax Alliance as an organization has not established a formal position on the debate of XHR2+AC, XDR or other similar cross-domain request proposals. ... But for IE9/FF4/Safari4/Opera.NEXT, let's please get together on this issue. I call on a good faith effort by the principal parties in this discussion to meet face-to-face and start work to hammer out a unified proposal that is acceptable to all. This is in fact one of two items for the next face to face. The other, hopefully secondary, is cleaning up any outstanding issues in XHR1 (since XHR2 depends on that in any case, and since there are several critical-path folks who are the same person). Of course, the meeting relies on timely input. We are waiting on Microsoft to raise specific issues so we can analyse them and put them on the agenda. I am hopeful that having scheduled a face to face meeting a couple of months away isn't taken as a reason not to continue the more aggressive process that would have been required to justify holding telecons, as Microsoft originally requested - there is certainly no barrier to holding telconferences before the meeting. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman <[EMAIL PROTECTED]> wrote: On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: ... I'm not really clear on why Blobs must be distinct from ByteArrays. As I read it, the Blob proposal also explicitly ties in a bit of file interaction (which is why it is related to the fileIO proposal). The only explanation is: "The primary difference is that Blobs are immutable*, and can therefore represent large objects." But I am not sure why immutability is necessary to have the ability to represent large objects. Reading through the rest of the discussion, I don't think it is - in general it would seem useful to have a ByteArray, IMHO. ... I also notice that you used int64 in many of the APIs. JavaScript cannot represent 64-bit integers in its number type. ... I think our assumption is that 2^53 is large enough to represent the length of all the blobs going in and out of web apps for the forseeable future. We would just throw when we receive a number that is larger than that saying that it is out of range. Is there a better way to notate this in specs? Well, you at least have to be pretty explicit about it I think. Better would be to find a type that Javascript can do, though. (I suspect that if we are still relying on a thing called 'blob' because we still don't have real file system access with some sense of security by the time we want to hand around a Terabyte in a web application, that we will have seriously failed somewhere. Although it isn't impossible that we end up there). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Mon, 12 May 2008 07:40:44 +0200, Chris Prince <[EMAIL PROTECTED]> wrote: On Sun, May 11, 2008 at 9:22 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote: On Sun, May 11, 2008 at 6:46 PM, Maciej Stachowiak > Open question: can a File be stored in a SQL database? If > so, does the database store the data or a reference (such as a path or Mac > OS X Alias)? There definitely needs to be a way to store Files locally. I don't have a strong opinion as to whether this should be in the database, or in DOMStorage, or in something new just for files. Which seems to me to bring us back to the fileIO idea. In the meantime, Arve (who is one of the people who did a lot of the thinking behind it) has been thinking about useful ways that it can be sliced and diced, making some functionalities more readily available to general applications, although I am not sure where his thoughts are at the moment. A reference has the problem that the underlying file could be modified by an external program. I think once you save data into the SQL database, you should be able to count on it staying constant, and valid. Well, that depends on whether you are saving a copy(-on-write) or a reference. There are cases where it is actually useful to be able to operate on the file beside what the application does in the database, despite the increased complexity this brings... So maybe it should be possible to store both, and at least to consciously seperate the two as ideas in any proposal. They have (IMHO) slightly different use cases. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [July 1-3] [face to face] Agenda?
On Tue, 13 May 2008 02:54:58 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote: Charles McCathieNevile wrote: On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich <[EMAIL PROTECTED]> wrote: Hello, I understood that prio 1 item on the july 1st-3rd agenda is going to be XHR2 (XDR... input). What other items are (known to be) on the agenda ? (probably 3 days are anyway just enough to finalize XHR) XHR and XHR2 (and friends and acquaintances) are the agenda as planned. I suspect that will eat 3 days :( If not, I would be looking for other small stuff we can do, or for stuff that people think is urgent for that meeting. (I would rather finish early, really, if possible). Are we planning on discussing Access-Control as well? Yeah, sorry. That goes with XHR2 in my mind. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [July 1-3] [face to face] Agenda?
On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich <[EMAIL PROTECTED]> wrote: Hello, I understood that prio 1 item on the july 1st-3rd agenda is going to be XHR2 (XDR... input). What other items are (known to be) on the agenda ? (probably 3 days are anyway just enough to finalize XHR) XHR and XHR2 (and friends and acquaintances) are the agenda as planned. I suspect that will eat 3 days :( If not, I would be looking for other small stuff we can do, or for stuff that people think is urgent for that meeting. (I would rather finish early, really, if possible). Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sat, 10 May 2008 06:15:01 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote: On Wed, 7 May 2008, Aaron Boodman wrote: The Gears team has also been putting together a proposal for file access which overlaps in some ways with Opera's, but is also orthogonal in some ways: http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal This seems like it would be something we may want defined in a small spec and then used by many others (like progress events) -- one spec to define Blob, and then the other specs to use it (like XHR and HTML5/WF2). That would seem like the way to go if we decide to take this on. The proposal is currently a small spec for one thing, after all. Do we have the resources to have someone champion this spec? Are you asking the WG, or Google? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Security Re: File IO...
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote: Hi folks, Opera has a proposal for a specification that would revive (and supersede) the file upload API that has been lingering so long as a work item. In a nutshell, it provides the ability for a web application to get a filespace, by asking the user to identify such a space, and making it available to that application something like a virtual file system. I am concerned about the security implications of this proposal. File upload in HTML is based on the user explicitly selecting a particular file. This has relatively low security risk, since the user is choosing one specific file that he or she wishes to transmit, and all that can be done with that file is upload its bytes. However, this API grants much more power than that. Yep. That's the idea. Here are some of the more obvious security issues: [several obviously interesting things] 6) Despite clearly having major security considerations, the document has no Security Considerations section. Indeed. (It also has no table of contents). There are obviously security issues any time you give access to something like the filesystem. That said, there are valuable use cases for access to the filesystem. The idea of standardising this currently rough proposal is that we identify and deal with those. An obvious approach would be to limit availability of this to "trusted content" for some definition of that (and different browsers currently have different definitions). As a work item we can happily raise the security issues and provide guidance about what circumstances open what kinds of risk. Which is what we would like to do, as part of making the functionality available to application developers in some way. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
File IO...
Hi folks, Opera has a proposal for a specification that would revive (and supersede) the file upload API that has been lingering so long as a work item. In a nutshell, it provides the ability for a web application to get a filespace, by asking the user to identify such a space, and making it available to that application something like a virtual file system. Use cases include single or bulk file upload (e.g for images, a set of files, etc), as well as allowing the creation of widgets that use a set of local files. For example, you could make a music player widget by giving access to a mountpoint that contains music files, and you could add music to that directory which would also be available to traditional applications on the system. This is a draft, and we expect it to change. Opera has implementation of this, and we will make available some experimental builds for people to play with in the near future. We hope that the working group will take this as a replacement for file upload so it can develop as a useful interoperable standard. A draft is at http://dev.w3.org/2006/webapi/fileio/fileIO.htm so you can have a look. All manner of feedback is of course welcome... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Proposal for Cross Site Requests
There has been rather more to-ing and fro-ing than actual work, it seems. I am happy to schedule a teleconference, and to ensure that Anne is available (as editor of XHR I think he is a critical resource). But we need to establish an agenda. (I am also trying to organise a face to face meeting to ensure that we can work as rapidly as possible - people are implementing stuff now and I would hate things to slow down to the point where people effectively opt out of the standards process and just ship something different). Before trying to schedule a teleconference, we need an agenda. As Maciej and others have noted, these are potentially complicated issues and we need to have reading time before the meeting in order to avoid wasting valuable teleconference time. The results of the survey on simply sopting IE's approach were pretty conclusive. The reasons given seem pretty clear, such as a desire not to fork requests in the first place, a belief that moving security risk from the implementation of requests to each specific use of a request actually increases the risk for end-users. Microsoft apparently feels that there are reasons to implement something other than the standard approach being developed, since they did so and I presume it was not from bloody-mindedness or ignorance. In order to usefully address these issues we need to understand them. Which means we are waiting on Microsoft to provide written feedback. Given the months that elapsed between the last time feedback was promised and when it was delivereed, I am reluctant to schedule teleconferences before such feedback is provided, at least sufficient to justify holding a teleconference. cheers Chaals (as chair, webapi woring group) On Sat, 03 May 2008 00:51:27 +0100, Sunava Dutta <[EMAIL PROTECTED]> wrote: Maciej wrote: " I would also prefer to see a clear statement of Microsoft's position in written form ahead of the telecon. By their nature, these are issues that need careful analysis, and cannot be evaluated fully in the context of a teleconference." I think the request will help discussion. Yes, we will be making our position and points that need further deliberation available in a written form prior to the teleconference. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 5:01 PM To: Ian Hickson Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public); [EMAIL PROTECTED]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey Subject: Re: IE Team's Proposal for Cross Site Requests On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote: On Tue, 29 Apr 2008, Chris Wilson wrote: Given the multitude of issues raised, and the obvious back-and-forth that denotes many differing opinions, I'd suggest having a telecom to discuss these questions, and make sure that Sunava, Eric and myself can attend. I'm with Anne on this. Please reply to the e-mails before convening a telecon. It is very difficult to carefully consider feedback in the context of a telecon. The problem isn't "back-and-forth" denoting "many differing opinions", the problem is that we don't know what Microsoft's opinion _is_. Telecons are by their nature much less open, and minutes are almost uniformly so poor that it is hard to impossible to get precise technical details out of telecons. A telecon would not be appropriate at this point. I would also prefer to see a clear statement of Microsoft's position in written form ahead of the telecon. By their nature, these are issues that need careful analysis, and cannot be evaluated fully in the context of a teleconference. Regards, Maciej -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: The XDR proposal from MS
On Sat, 12 Apr 2008 00:16:30 +0800, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: Microsoft has suggested [1] that the WebAPI group take on the XDR spec as a deliverable We will therefore hold a survey of Working Group members, to determine how much support there is for this The rough survey results should be available in about two weeks. Note that this will not be a binding vote - it is an attempt to clarify the general level of support and help determine the best way forward. [1] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0204 So we held the survey, and in the Working Group there was no active support and a substantial number of objections to the proposal on several technical points. We will of course look at the ideas that led MS to consider a completely new approach. Considering each of the issues that the new proposal was designed to solve is a natural part of the development of XHR 2. But as things stand the working group will not adopt XDR as a deliverable. cheers Chaals (chair) -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
The XDR proposal from MS
Hi folks, Microsoft has suggested [1] that the WebAPI group take on the XDR spec as a deliverable. (For other administrative reasons, the WebAPI group as a whole may have a successor group that is slightly different, but broadly would include the same set of deliverables. For now I am assuming that there will be a WebAPI group or something recognisably the same thing long enough to work on such a spec). We will therefore hold a survey of Working Group members, to determine how much support there is for this. Since this is an administrative matter, it is not open to the public under the current charter - we will however publish the result (in aggregate form). Because most discussion has taken place on teh public list already, and because openness is generally good, I encourage people who have anything to add to the discussion to continue with the public thread (changing subjects as necesasry please, for people who try to follow the archive later. The rough survey results should be available in about two weeks. Note that this will not be a binding vote - it is an attempt to clarify the general level of support and help determine the best way forward. [1] http://www.w3.org/mid/[EMAIL PROTECTED] cheers Chaals (chair of WebAPI) -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
XDR and bike sheds Re: What is Microsoft's intent...
On Fri, 28 Mar 2008 02:22:41 +0100, Sunava Dutta <[EMAIL PROTECTED]> wrote: Agreed. I think it's entirely reasonable to call XDR by its full DOM name, XDomainRequest. Which, just as XMLHttpRequest is habitually shortened to XHR, will be shortened to XDR in the real world. I don't think we can avoid all name clashes - we should look at the one that are close in functionality and try to avoid those in particular. cheers Chaals -Original Message- From: Stewart Brodie [mailto:[EMAIL PROTECTED] Sunava Dutta <[EMAIL PROTECTED]> wrote: IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. Whatever you decide to do, please could you choose a different acronym, as XDR is already used for encoding in RPC. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Charter arcana Re: Updates to Bindings spec, republish?
On Thu, 27 Mar 2008 10:46:54 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: Would be great. If W3C grants us a charter extension we can republish - Oops. As Cam pointed out to me privately, our charter runs to the end of April, which is enough time to republish. (It just isn't enough time to plan other stuff like meetings :( ). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Updates to Bindings spec, republish?
On Wed, 26 Mar 2008 02:06:38 +0100, Cameron McCormack <[EMAIL PROTECTED]> wrote: Hi group. I’ve made some more changes to the Bindings spec recently: ... Other changes since the FPWD are listed in the “Changes” section of the document. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.63&content-type=text/html;%20charset=utf-8 I think the document would benefit from being republished at this point. Charles/Doug? Would be great. If W3C grants us a charter extension we can republish - in the meantime I will start the call for consensus. (For folks following this public list, that's a formal administrative thing for working group members. I would be surprised if it didn't pass - I don't think we have ever blocked publication of an updated working draft). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Regrets Re: DOM3 Events Telcon Agenda, 05 March 2008 (Today!!)
Sorry, I will not be there - I will be in a plane :( cheers Chaals On Thu, 06 Mar 2008 03:08:47 +0900, Doug Schepers <[EMAIL PROTECTED]> wrote: Hi WebAPI WG- This is a reminder that will will have a DOM 3 Events telcon today (I should have sent this yesterday). The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: # mousewheel issues For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past and planned telcons, with a brief summary of issues discussed. [3] [1] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time [2] http://www.w3.org/2008/webapps/wiki/5_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Requirements... Re: Progress events progress...
On Fri, 22 Feb 2008 21:31:42 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote: On Fri, 22 Feb 2008, Charles McCathieNevile wrote: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.20 is a new Editor's draft, which should be ready to publish as a Working Draft, and hopefully not generate any comments so we can take it to last call about a month after that :) I'm all in favour of publishing. Noted. I don't understand the conformance in this spec. When a spec has two classess -- UAs and authors -- it's usually easy to tell which requirement applies to which. But when you add specs to the mix, I don't know how to tell which requirement applies to what. In particular, this, combined with the apparent lack of requirements on some things but presence of requirements on others, leads me to have great difficulty interpreting the actual requirements in the spec. OK, I will try to make them simpler and clearer. For example: ... Incidentally, I _really_ don't understand the definition of the User Agent conformance class: | A conforming user agent implements all the requirements described for | user agents throughout this specification. A conforming user agent | should implement all the recommendations for user agents as well. First, why is there a conformance requirement in the definition of the conformance class to which it applies? The definition of the conformance class is the primary place where the conformance requirements for that class are described, although in practice it is just a reference to various other places in the spec - at this time the reader is expected to read through the spec and identify those, but as you were apparently unable to do so I take it that I need to make it simpler. I am not sure how else you would define a conformance class... Second, aren't those two sentences contradictory? No. You MUST do the things that are a MUST, and you SHOULD do the things that are a SHOULD. That struck me as a very straighforward proposition. Maybe I will try to say it more in those words. ... Frankly, as the editor of a spec that tries to use this spec, I'm not sure what would be best. I'm thinking that one option would be to change the focus of the Progress Events spec to be more of a guide, with the normative parts being only the definition of the IDL, with its methods defined in line with the DOM Events spec and the DOM Bindings spec, and with everything else just left up to the specs using it. The spec would then give a guide as to what event names are expected , in what order, but without making this normative. I think it is useful to define the events normatively to allow for interoperable use of them amongst multile specifications - for example user agents handling SVG and HTML. (I've already had to deviate from what this spec requires, mostly due to having more events to fire.) In what way did you have to deviate? The spec allows you to add any more events you want, it just defines particular events and the relation between them. Does your work on this change the names or order of the things defined in the current draft, which were left that way because they matched earlier drafts that were implemented in user agents or just add new events that you define yourself? (Do you have a handy pointer? I assume you mean the HTML spec but for some reason that is not currently loading for me) To make this slightly more useful, maybe some "macros" could be defined, similar to the "fire a simple event" macro I have in HTML5, but like "fire a progress event" which takes "arguments" like the event name, the progress, the total, and the target element, with the "macro" setting up the bubbling and canceling behaviour, etc, and "returning" whether or not the event's default action should fire. I am not sure about this. I don't know if it makes sense to have authoring conformance requirements for this spec at all. I believe it does. Which is why they are in the spec. Do you want a formal issue raised? Anyway. HTH, Thanks... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Progress events progress...
Finally... http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.20 is a new Editor's draft, which should be ready to publish as a Working Draft, and hopefully not generate any comments so we can take it to last call about a month after that :) I have resolved all outstanding issues, as per http://www.w3.org/2006/webapi/track/products/12 which just shows there are none left, not what they were :( But they are linked from the change history in the draft, with their resolution. So it should be good to go. If there are things that are still not sorted, please let me know... Otherwise, enjoy... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: SVG copy and paste between applications?
On Tue, 19 Feb 2008 11:44:57 +0100, ~:'' ありがとうございました。 <[EMAIL PROTECTED]> wrote: Chaals, Erik & Irène, Are we near being able to copy and paste svg symbols that are externally referenced with between applications? consistently and reliably across applications? I don't think so, which is a shame. The clipboard APIs spec [1] draft has some idea about how it should be possible, in the same way as it should be possible to drag and drop things in a web application, to copy things like the external use reference, or the object itself, or various other possible things that you might choose when "selecting" and object. But that spec is languishing for lack of an editor. [1] http://www.w3.org/TR/clipboard-apis cheers Chaals regards Jonathan Chetwynd Accessibility Consultant on Media Literacy and the Internet In Amaya, open: http://peepo.co.uk/temp/use-external.svg copy, paste and save the sun symbol: xlink:href="http://upload.wikimedia.org/wikipedia/commons/ 5/50/Weather-icons.svg#sunny" /> in a new document then open in Opera 9.5 -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Fwd: Re: [css3-namespaces] upcoming last call for the CSS3 Namespaces Module
FYI. If anyone thinks we should comment as a group, please say so and we will look at the comments (and get an extension if necessary to ensure that we make comments we agree on) cheers Chaals --- Forwarded message --- From: "Bert Bos" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "Hypertext CG" <[EMAIL PROTECTED]> Subject: Re: [css3-namespaces] upcoming last call for the CSS3 Namespaces Module Date: Sat, 16 Feb 2008 00:04:59 +0100 The draft has now been published and the deadline for comments has been set to March 7: http://www.w3.org/TR/2008/WD-css3-namespace-20080215 Bert -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [XHR] Editorial - labelling sections
On Wed, 13 Feb 2008 01:28:46 +0100, Anne van Kesteren <[EMAIL PROTECTED]> wrote: On Tue, 12 Feb 2008 20:01:30 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: working through the first test case I looked at, sections of the document seem to be quite large. I believe it would be helpful if there were a more granular breakdown of sections, and a more detailed table of contents, in order to refer in more detail to important parts of the spec. This is changed in XMLHttpRequest Level 2. I rather not change the whole structure for XMLHttpRequest Level 1 as we've had this structure since the beginning and changing it will be quite some editorial work with a high risk of introducing errors. Each member of the interface has a unique identifier so you can easily point to them. You mean in the source? If so, putting in an expanded table of contents somewhere that links in more detail, so I could see and copy/paste the relevant link without reading the source would be extremely helpful. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
[XHR] Editorial - labelling sections
Hi All, working through the first test case I looked at, sections of the document seem to be quite large. I believe it would be helpful if there were a more granular breakdown of sections, and a more detailed table of contents, in order to refer in more detail to important parts of the spec. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Feedback on the XHR Draft
On Mon, 11 Feb 2008 21:18:41 +0100, Sunava Dutta <[EMAIL PROTECTED]> wrote: That is correct. Thanks Hallvord! right. As part of the process of checking the test suite and approving it through the workig grou, we will need o make it so people can use it locally - including explaining server-side magic, associated files, etc. cheers (and thans Hallvord for your own work on this, which has been invisible for the most part but important and appreciated) chaals -Original Message- From: Hallvord R. M. Steen [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 12:18 PM To: Charles McCathieNevile; Sunava Dutta; Chris Wilson Cc: public-webapi@w3.org; Gideon Cohn; Zhenbin Xu; Marc Silbey; Ahmed Kamel Subject: Re: IE Team's Feedback on the XHR Draft On Sat, 09 Feb 2008 11:37:17 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: Would it be possible once the tests are relatively stable to package them (including reference files) and send us a copy? We will have them on the Web - you have to fetch your own copy That's a quite legitimate question because there are some server-side scripts there. I assume this was what Sunava meant by talking about inaccessible resource files earlier (to the best of my knowledge none of the tests rely on hard-coded URLs to Opera's intranet or nonsense like that!). It's not possible to access the SVN repository for those tests anonymously, is it? -- Hallvord R. M. Steen Core QA JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: XHR test cases vs HTTP methods
On Sat, 09 Feb 2008 17:42:20 +0530, Anne van Kesteren <[EMAIL PROTECTED]> wrote: On Sat, 09 Feb 2008 12:57:18 +0100, Julian Reschke <[EMAIL PROTECTED]> wrote: ...looking at <http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/006.htm>... It seems there are no test cases that check that a user agent either correctly handles unknown method names, or rejects them with an SECURITY_ERR exception (<http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070618/#dfn-open>). I'm not sure how you conclude that from that testcase, but you're right, the testsuite is not complete. As I noted, please don't expect Anne to write the entire test suite - that isn't his job. We expect the participants of the working group in particular to contribute tests - although they are welcome from anyone... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: XHR test http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm
On Sat, 09 Feb 2008 17:21:25 +0530, Anne van Kesteren <[EMAIL PROTECTED]> wrote: On Sat, 09 Feb 2008 12:38:16 +0100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: I suggest we declare this test invalid, and either replace it and declare it valid only after such date as it is fixed, or simply add a new test that gets the correct file. Fixed. So results before today are useless. Do we explain that anywhere? Some browsers still fail, but given that they all treat invalid XML documents in different ways that was sort of expected. Which ones? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
XHR test http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm
Hi, this test says it checks what happens when you load an invalid XML document. Unfortunately it actually loads the wrong document at the moment - http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/support/008.xml (which is well-formed) instead of http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/support/009.xml which has an ampersand and is not well-formed XML. I suggest we declare this test invalid, and either replace it and declare it valid only after such date as it is fixed, or simply add a new test that gets the correct file. The test checks one aspect of step 3 in the part of section 4 that deals with "XML response entity body", which requires that content which fails XML well-formedness should have a responseXML of null - in this case the responseXML should be null because the file loaded contains an unescaped ampersand. I could not find any issue raised and resolved for this in the issue tracker, but it is mentioned in a thread at http://lists.w3.org/Archives/Public/public-webapi/2007Feb/thread.html#msg088 followed by an apparent summary at http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0090 (I am assuming, since the summary there matches what I understand the document to say on this point). If we make the change, what is the conformance status? Given that http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/006.htm (which also tests XML well-formedness errors giving null responseXML) is not one of the tests failed by a lot of browsers, I suspect the issue will go away, but I haven't actually run the tests on other browsers yet. So I suggest there is no real issue here, just an incorrect test. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
XHR tests
Hi folks, According to MS' testing 4 major browsers (I am guessing they mean Opera, Safari, Mozilla/FF and IE although I am not actually sure) all fail the following tests. It would be helpful to check them against the spec and as tests to determine whether there is some simple bug we should fix. If people are prepared to take on the task of analysing them, we should be able to start making these official or raising issues where this has not already happened. Note that I will look at the first one on this list - http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm If we are going to have decent test coverage, we need to do this not just for these tests but for those we agree are valid tests, so don't be shy about volunteering for a handful of tests and checking them. cheers Chaals http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/011.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/013.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/016.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/024.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/026.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/027.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/030.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/031.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/002.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/006.htm http://tc.labs.opera.com/apis/XMLHttpRequest/abort/008.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/006.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/010.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/011.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/complex/001.htm -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Feedback on the XHR Draft
On Sat, 09 Feb 2008 09:39:07 +0530, Sunava Dutta <[EMAIL PROTECTED]> wrote: Thanks Charles. I agree with your plan... ... Running a full-fledged test suite against our browsers to verify interop is a critical next step that should happen before CR. We’d appreciate it if the tests can be matched with the spec by linking the relevant test to the spec section if possible (may be tough) or linking them at the bottom. This is a detailed spec and it will help. I think we need to work through these as a group and check where the tests match. Expecting Anne to do all that is unreasonable (apart from anything else, as his manager I would like him to work on other stuff too). We’ve run the test suites as promised in addition to giving feedback. I realize the tests may be incomplete and lots of reference files are not accessible to us. For interoperability, if a test does fail on all browsers (right now 32 fail on 4 major browsers using the incomplete existing suite. See bottom) I would say it would be useful to have a plan for a default given that this is an existing feature that’s been on the web for a decade? ... Either way, we recommend resolving these deltas to determine behavior Yep. Essentially it seems we are agreed to go to last call, but we will need to have some reasonable belief that people will fix implementations to pass tests (or decide that we should change the spec) if we expect to get out of CR. By the way, we welcome tests from anyone. We use Anne's because he has worked hard to make them, but there is no reason he should be the sole source of tests. and LC may be an appropriate time to do this. Yes, I think that is the emerging consensus... Would it be possible once the tests are relatively stable to package them (including reference files) and send us a copy? We will have them on the Web - you have to fetch your own copy :) But yes, it should be possible to download a package for local use once we have an official test suite. Reemphasizing what Chris mentions, we do believe that detail is good as long as it's readable and easy to assimilate. I humbly suggest removing or in the minimum mentioning which parts are UA implementation details that are not necessarily binding... Basically, you either convince the editor directly about editing changes, or you need to propose specific changes to the group (which can override the editor even on editorial matters) so it can make a decision. Both of these are legitimate processes, but in the latter you're unlikely to make much headway without very clear proposals (i.e. "change FOO to read BAR"). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Feedback on the XHR Draft
On Sat, 09 Feb 2008 06:21:18 +0530, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Feb 8, 2008, at 12:03 PM, Charles McCathieNevile wrote: On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson <[EMAIL PROTECTED]> wrote: 2) In fact, on that note, we're interested to see the test suite be linked, normatively if necessary. Yes. I think this is a valuable piece of feedback. Currently W3C process doesn't require test suites until you're trying to get out of CR and I think it would be better to have them earlier. I agree that official test suites should be developed earlier than CR. Noted. ... Fortunately, we have unofficial test suites as a starting point. Yep. However, I think that per standard practice the test suite should not be considered normative, only the text of the spec. This is the case traditionally for W3C which was once very test-shy and spec-friendly. I think that the moves towards accepting tests as normative is not necessarily a bad idea... In particular, conformance requirements that are not covered by a test must still be binding, I agree with this and in case of conflict between the test suite and the spec, the spec must win. I'm not so sure about this. Interpreting test results is often easier to do unambiguously than interpreting spec language. Ultimately whether we endorse the spec or a test, we have to carefully look at them both and do our best to ensure they really do match... Of course, if the test suite and the spec ever disagree we will have to publish bug fixes to the test suite or errata to the spec, but in the meantime we need to be clear which is normative. agreed. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: IE Team's Feedback on the XHR Draft
On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson <[EMAIL PROTECTED]> wrote: I think there are a few misconceptions about Sunava's feedback. 1) In NO WAY do we want the specification to be less detailed. MORE detailed, if anything. Yeah, we cleared that up at the technical plenary in my mind. 2) In fact, on that note, we're interested to see the test suite be linked, normatively if necessary. Yes. I think this is a valuable piece of feedback. Currently W3C process doesn't require test suites until you're trying to get out of CR and I think it would be better to have them earlier. 3) we are not intending to block last call, and we understand the Process. Sunava had promised to send comments, and has done so. We would still like to see these comments addressed in the specification, and not simply dismissed; whether that is prior to or post LC is not, I think, that important. OK, thanks. I have no intention of simply having comments dismissed. I have held the last call question open to allow for a sensible discussion. What I am thinking now is that we should check whether there are substantive comments that need to be addressed before LC (on my first reading I don't think so), and continue pretty fast to last call. I would like the group to start checking the test cases we have against the spec and formally agreeing them to facilitate this linkage during last call. It slows down the LC period, but it should make CR easier and reduce the possibility of reverting from CR. How do people feel about that as an approach? Finally, on the question of what we agreed at the technical plenary, the minutes do not reflect any resolution that we agreed we would make a spec that is 100% compatible with IE - as Anne, Jonas and Maciej pointed out we started out working from existing implementation including IE and trying to make a spec that is as backwards compatible as possible, but that is *a* goal not the driving requirement. Naturally any specific requests for technical changes are welcome either now or during Last Call, and will be considered on their merits. We had hoped that any such comments would have come in already but one of the reasons for going to last call when we have run out of comments at normal working draft is to elicit any outstanding issues. So I plan to give it a few days (I am only partly available over the next few days, in India, Poland, Spain, Norway in the next week) and then I'll propose a formal consensus call on a way forward - based on the above thoughts and comments here over the next week. cheers Chaals -Original Message- From: Doug Schepers [mailto:[EMAIL PROTECTED] Sent: Friday, February 08, 2008 1:54 AM To: Maciej Stachowiak Cc: Anne van Kesteren; Sunava Dutta; public-webapi@w3.org; Gideon Cohn; Zhenbin Xu; Chris Wilson; Marc Silbey; Ahmed Kamel Subject: Re: IE Team's Feedback on the XHR Draft Hi, Folks- To be clear, I'm not critiquing the spec itself, or advocating any specific action. Rather, I'm trying to manage expectations and ensure that the various participants of this WG can work smoothly with one another. I'm acting purely as a Process wonk here. Sunava, as you see, there is considerable, and reasonable, incentive to make the XHR spec as detailed as possible, even where it may not match the IE implementation precisely. Maciej's request for more specific details on potential conflicts (in implementations or content) is appropriate, I think. I don't know if you are familiar with the W3C Recommendation Track [1], so briefly, you should know that LC (Last Call) is not the end of the process. It simply indicates that the specification is believed to have satisfied its technical requirements; it's not considered stable enough for implementation, and in practice, this is when most comments are made. Thus, I see little harm in advancing to LC, since you will still have an opportunity to submit additional technical comments. [1] http://www.w3.org/2005/10/Process-20051014/tr Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [selectors-api] Best practice in HTML wellformed documents
On Wed, 02 Jan 2008 17:06:43 +0100, Lachlan Hunt <[EMAIL PROTECTED]> wrote: ... While XHTML imposes the requirement to explicitly close all elements, it is not required in HTML. In HTML, end tags for some elements, including those above, may be omitted. This is a feature inherited from HTML's origin as an application of SGML. ... I decided to omit the end tags from the markup because they were unnecessary, it made the example markup smaller and, IMHO, clearer to read. Therefore, since the current example actually is conforming, I have not changed it at this time. Please let me know if you are not satisfied with this response. I have a personal preference for using well-formed XHTML for examples over HTML - it is easier for me to see where the element boudaries are, so the small price in verbosity gives greater clarity. It is also simpler to copy/paste into an XHTML *or* HTML document and have it work. As far as I know the group has never resolved a particular preference for terse HTML markup over XHTML. Does anyone think that the value of such a resolution would justify the debate it will entail? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Selectors API in Last Call
Hi folks, Selectors API [1] has now moved to last call. We had a long delay in publishing while we waited for announcement of our charter extension, so we are extending the deadline for review comments until 31 january. This spec provides an API similar to getElementsById which allows you to use CSS-style selectors to specify the things you are trying to collect. Reviews should be sent to this list public-webapi@w3.org We would strongly prefer not to have to grant extensions, in particular because we run out of charter on 31 Jan, and will need to go through more administrative hoopla to do anything (on past form this suggests a couple of months hiatus although I hope we manage not to do that this time). So please try to get your reviews done early. [1] http://www.w3.org/TR/2007/WD-selectors-api-20071221/ cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
was Re: names lengthComputable and total
Stripped the issue marker, this seems more about general process. On Mon, 10 Dec 2007 21:14:16 +0100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Dec 10, 2007, at 11:16 AM, Charles McCathieNevile wrote: On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: What would look compelling to me is web content depending on the specific names. That's more important than whether someone shipped an implementation. That could indeed be a much more compelling argument. Can you show that such content does or does not exist? As far as I know, it does not. I think the burden of proof would be on anyone who wants to claim it does. I don't think anyone is claiming this, though. I would imagine that some content exists, and if we hassled Ikivo we might find it. But I don't imagine a significant body of content (although it is theoretically possible). Having an implementation that is difficult to change, shipped in millions of devices, does seem like an argument of some strength in the absence of a strong counter argument. I don't think the API we design for the Web should be driven by non-Web uses like JSR-280. It's nice when they can benefit, sure, but the W3C's mission is the Web. That would be about my take on it too. It is also nice when we benefit from similarity in work they have done, so it is not entirely one-way. The fact that there is also web implementation (Ikivo is used in Web browsers as well as web-like products) is significant IMHO. I'll admit that method naming isn't the biggest issue. But it seems like bad precedent to start giving weight to external standards that copy very early stage W3C standards, as this subverts the W3C's own standards process, which runs by different rules than the Java Community Process. The base specification has been around for a long time (we inherited it from SVG), and it was pretty baked already. People have implemented, people have written it up (although it is only draft), and based other stuff on it. Others have just chosen equally bad names for the same thing. And fundamentally, this naming issue doesn't seem to be a really big deal. The spec has been significantly reworked since it started. lengthComputable in particularly was removed entirely for a while and added back in March 2007. The whole event design was changed significantly based in part on my feedback. I'm not sure we can consider it "pretty baked". YMMV This specific issue isn't that big a deal. However, in the past in other working groups, the argument "we can't change this because it's in JSR-something-or-other" was used many times to reject comments that pointed out serious substantive problems with the spec. What other working groups do is a rough guide to what we might do. I am sympathetic to JSRs, but I waited until I had confirmation of the non-JSR work before making a "final" decision here (and as we have agreed, the issue is hardly a big one). I have equally been happy to run against JSR when it seemed the right decision. So I think we are in broad agreement. (The devil, of course, will always be in the details, and those will come out case by case). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ISSUE-119: names lengthComputable and total
On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Dec 10, 2007, at 8:17 AM, Jean-Yves Bitterlich wrote: Maciej Stachowiak wrote: In general I don't think we want to set a precedent of locking in bad names in Editor's Drafts without a compelling reason. An implementation alone is not much reason, there would have to be significant content depending on it. agreed. However, JSR-280 is Final Release: i.e. a Reference Implementation (RI) as well as a Test and Compatibility Kit (TCK) are available and licensed/licensable; Moreover a development kit is also available and compliant. This looks compelling enough ... to me :-) What would look compelling to me is web content depending on the specific names. That's more important than whether someone shipped an implementation. That could indeed be a much more compelling argument. Can you show that such content does or does not exist? Having an implementation that is difficult to change, shipped in millions of devices, does seem like an argument of some strength in the absence of a strong counter argument. I'll admit that method naming isn't the biggest issue. But it seems like bad precedent to start giving weight to external standards that copy very early stage W3C standards, as this subverts the W3C's own standards process, which runs by different rules than the Java Community Process. The base specification has been around for a long time (we inherited it from SVG), and it was pretty baked already. People have implemented, people have written it up (although it is only draft), and based other stuff on it. Others have just chosen equally bad names for the same thing. And fundamentally, this naming issue doesn't seem to be a really big deal. Given the relative unimportance of method naming, in the interests of building on and further developing a consistent body of material, of building more trust in the work we have done, and of moving forward, it seems to me a reasonable choice in this case to maintain compatibility with what we have had for a couple of years or so. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ISSUE-119: names lengthComputable and total
Ikivo have told me that they also implemented already with the existing event names, and would write to say so. I am therefore resolving this issue by not changing the names. cheers Chaals On Mon, 05 Nov 2007 21:34:50 +0100, Jean-Yves Bitterlich <[EMAIL PROTECTED]> wrote: Hi, To the question in ISSUE-119 whether "[...] they already get implemented with these names somewhere?", the answer would yes given that the Final Release of "JSR-280 XML API" (http://www.jcp.org/en/jsr/detail?id=280) defines the following methods based on the already existing names: |boolean| |*getLengthComputable *()| Specifies whether the total size of the transfer is known. | int| |*getLoaded *()| Specifies the number of bytes downloaded since the beginning of the download. | int| |*getTotal *()| Specifies the expected total number of bytes of the content transferred in the operation. Charles McCathieNevile wrote: Anne opined, a while ago, that these two attributes should have names more closely related. In my request for further information, nobody said they had any great reason for keeping the current names. I therefore propose to resolve this issue by changing the name "lengthComputable" to "totalKnown". Any objections? cheers Chaals Jean-Yves Bitterlich, Senior Staff Engineer Sun Microsystems GmbH, Sonnenallee 1, 85551 Heimstetten, Germany Geschäftsführer: Wolfgang Engels, Dr. Roland Bömer; Vorsitzender des Aufsichtsrates: Martin Häring Amtsgericht München: HRB 161028, WEEE-Reg.-Nr. DE 20803943 HypoVereinsbank München, Konto 31 625 009, BLZ 700 202 70 -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: ISSUE-118: Cancel / bubble Arg definitions
I have clarified in a new Editor's draft to be published tonight (if I can retrieve my ssh keys from a disk failure - otherwise probably tomorrow so I can get new ones) that the events follow the normal pattern for DOM 3 events (assuming I wrote the right stuff this time;) ). cheers Chaals On Tue, 31 Jul 2007 18:03:00 +0200, Web APIs Issue Tracker <[EMAIL PROTECTED]> wrote: ISSUE-118: Cancel / bubble Arg definitions http://www.w3.org/2005/06/tracker/webapi/issues/118 Raised by: Cameron McCormack On product: All If I understand it correctly, Bjoern [1] and Cam [2] are making the same point - that the definition of how cancelable and canBubble work is contradictory to the one in DOM 3 Events. (If this is the case then I think they should just be changed to be consistent. If I have misunderstood something else, I will find out soon enough I hope). [1] http://lists.w3.org/Archives/Member/member-webapi/2007Jul/0020.html [2] http://lists.w3.org/Archives/Member/member-webapi/2007Jul/0021.html -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: ISSUE-120: Make XHR spec less detailed/granular
On Sun, 28 Oct 2007 11:56:29 -0400, Web APIs Issue Tracker <[EMAIL PROTECTED]> wrote: ISSUE-120: Make XHR spec less detailed/granular I haven't seen any support for this at all, and opposition on the grounds that it makes interoperability less likely. I propose that unless someone else objects this week, we close this issue by resolving not to make the specification less detailed (although changing given details is a perfectly reasonable thing to propose). In the event that there is no other support for the objection and the resolution is to reject it, Microsoft are welcome to maintain a formal objection which will be carried along with the spec through further progress until resolved higher up the W3C process hierarchy. cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
ISSUE-119: names lengthComputable and total
Anne opined, a while ago, that these two attributes should have names more closely related. In my request for further information, nobody said they had any great reason for keeping the current names. I therefore propose to resolve this issue by changing the name "lengthComputable" to "totalKnown". Any objections? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: [progress-events] stalled - ISSUE-117
I propose to close ISSUE-117 by not including a stalled event. See below for some more history... cheers A while ago, Hixie wrote... On Tue, 31 Jul 2007, Charles McCathieNevile wrote: Maciej volunteered that > Somebody pointed out> > * HTML 5 has an event called "stalled" that is dispatched after> > there are three seconds of no progress at all so you do not have to> > create your own timer scripts. >> 3 seconds of no progress might not be out of the ordinary depending on > connection speed and distance to the host. This seems pretty> arbitrary. I agree with Maciej on this one. I raised ISSUE-117 for it, but my proposal is that we do not adopt it (and that we point out to HTML-WG that 3 seconds is very arbitrary). This would be consistent with how we dealt with ISSUE-107... To clarify -- in the HTML5 spec the three seconds is indeed arbitrary, the spec just says "about three seconds" and it is expected that user agents will adapt that as appropriate based on the connection speed, distance to host, and so forth. Furthermore, in the HTML5 case it's specifically for streaming multimedia, where the user does care about a few seconds with no buffering going on since it can mean that the media will skip. I agree that it may well be inappropriate to have this event in the progress events metaspecification. If it's included at all, it should probably be listed as something that specifications should only include if it is considered useful for that particular case. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Progress draft, cancel/bubble
A while ago Cameron wrote: ... That the values for canBubbleArg and cancelableArg are ignored is not consistent with other events defined in DOM 3 Events, which says that each “overrides the intrinsic bubbling [/cancelable] behavior of the event”. Raised ISSUE-118. Removing what it says there and deferring to D3E would be consistent with the bit that says D3E is the normative reference. But that would overturn the decision that the events must not foo (I am happy to overturn that decision if the group is), which is reflected in the must statement after the table of events. I propose to change the spec and let is say what Cameron suggests (i.e. to clarify the current difference between Progress and D3E in line with how Progress says it should be clarified),and thus to close this issue. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: Consensus Call Re: [XMLHttpRequest] Publishing another draft
On Mon, 08 Oct 2007 08:58:34 +0200, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: On Thu, 04 Oct 2007 15:35:47 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: I think it would be good if we published another draft of XMLHttpRequest Agreed. This is therefore a call for consensus - if you do not support publishing a new draft based on teh current editors' draft, please say so in mail to this group before Monday 15 October. Silence is assumed to be assent, although positive assent is preferred. Having seen no objections to publishing the draft, the resolution is that we would like to publish as soon as possible a new W3C Public Working Draft based on the current editor's draft. cheers Chaals with his chair hat on. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Consensus Call Re: [XMLHttpRequest] Publishing another draft
On Thu, 04 Oct 2007 15:35:47 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: I think it would be good if we published another draft of XMLHttpRequest Agreed. This is therefore a call for consensus - if you do not support publishing a new draft based on teh current editors' draft, please say so in mail to this group before Monday 15 October. Silence is assumed to be assent, although positive assent is preferred. And Opera agrees with Anne ;) ...A more detailed changelog of these changes can be found here: http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest/Overview.src.html.diff?r1=1.120&r2=1.146&f=h The latest editor draft can be found here: http://dev.w3.org/2006/webapi/XMLHttpRequest/ cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try the Kestrel - Opera 9.5 alpha
Re: [XHR2] XMLHttpRequest and progress events
On Thu, 02 Aug 2007 23:20:14 +1000, Anne van Kesteren <[EMAIL PROTECTED]> wrote: On Sun, 29 Jul 2007 03:04:14 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> ...Can someone explain to me how the user agent knows how much content it already has uploaded? It would need the network layer to tell it. Any suggestions on how to describe this in the specification? Why does it need to be in the specification? But if the UA doesn't know how much it has uploaded, is there a problem? The progress spec doesn't actually give any clues about what to do in that case (except not give a progress event if you have no idea that you made progress, which is implicit rather than stated). Should it say something else? Should we dispatch a loadstart event on that object as well even though it will be at the same moment it is dispatched on the XMLHttpRequest object? When to dispatch the progress events and abort, error, etc? Don't know the answers to these, but I think it would be helpful to get a complete set of events for an upload, in other words, the same set you'd get for the corresponding download. I suppose that makes sense. I suppose abort would be dispatched when abort() is invoked and data is still being uploaded or when the user aborts the upload while data is being uploaded. error would be dispatched because of some network error and load would be dispatched whenever the "network layer" (however we're going to translate that into specification terminology) says it's done. Makes sense to me too. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] http://snapshot.opera.com - Kestrel (9.5α1)
Re: future/draft/current W3C specs on multi-cursor / multi-touch ?
On Thu, 20 Sep 2007 01:32:10 +0200, Ruud Steltenpool ( http://svg.startpagina.nl ) <[EMAIL PROTECTED]> wrote: How ready are webstandards for multi-cursor and multi-touch GUIs ? Hi Ruud, This has been under discussion in the group for quite a while - see http://www.w3.org/2006/webapi/track/issues/33 - ISSUE-33. At the moment we don't have any resources in the group to work on it :( Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] http://snapshot.opera.com - Kestrel (9.5α1)
Fwd: Re: [whatwg] Progress Events "done" event
Forwarded and reply-to set to webapi-public, which is where you should
send things you want actively considered for the W3C progress events spec.
That's the group working on the spec.
I think there is enough detail left in the mail below for webAPI people to
get this. The idea is that it might be helpful to add a "done" event that
could be trapped instead of having to get the seperate possible events
that mean you are done.
I'm inclined not to add a "done" event. It invites code repetition in the
browser, which is not helpful in the case of mobile browsers. Also, I
think the example doesn't take into account that where the load is
aborted, or wherer there is an error, you often want to pass by some
relevant function such as explain what happened before calling the code to
clean up the progress bar.
Since progress events are used by other specs, they can add a done if they
really want. But it turns out that for example XHR has onreadystate change
which you can use to get the same info.
What do others think?
Cheers
Chaals
--- Forwarded message ---
From: "Garrett Smith" <[EMAIL PROTECTED]>
To: "Křištof Želechovski" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [whatwg] Progress Events "done" event
Date: Mon, 10 Sep 2007 23:33:20 +0200
On 8/27/07, Křištof Želechovski <[EMAIL PROTECTED]> wrote:
Remember that JavaScript is a programming language after all. You can
use a
loop to get rid of the repetitions.
Start from
var done = ["load", "error", "abort"]...
and apply the closure image.aEL(?, hPB, false) to it.
Sincerely,
Chris
That is true, in fact, it would also be possible to use Array.forEach
on that array.
The disadvantage is that it still invites code repetition. It is less
concise.
On the contrary:
xhr.addEventListener("done", callCompleteHandler, false);
function callCompleteHandler(e) {
}
Translates the use case to code quite naturally.
I like to make these examples that are conceptually similar:
"I'm going to call my friend and then I'm going to the dry cleaner."
vs.
"I'm going to call my friend and if she's not available, after that,
I'm going to the dry cleaner and if the call failed, after that, I'm
going to the dry cleaner, and if we talk for a bit, after that...
You get the point. English doesn't have loops or generators (hey
wouldn't that be cool!).
My point is that having a done event is more concise and makes
realizing the use-case requirement to code more explicit.
Garrett
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [whatwg] Progress Events "done" event
==
function showImage(imageHref) {
...
// remove the progress bar when done.
image.addEventListener("load", hideProgressBar, false);
image.addEventListener("error", hideProgressBar, false);
image.addEventListener("abort", hideProgressBar, false);
}
======
This is somewhat verbose. Clearly, the author is forced to repeat
himself when all he really wants to do is hide the progress bar after
the call is done.
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
[EMAIL PROTECTED] http://snapshot.opera.com - Kestrel (9.5α1)
Fwd: SMIL 3.0 Last Call Review.
FYI. You can send individual comments - if you want to sent WebAPI group endorsed comments, please make a proposal to the list by 5 September. cheers Chaals --- Forwarded message --- Hello, We have invited comments from the following groups on 13 Jul 2007 [1] and send a reminder today. [2] : - the XForms Working Group - Timed Text Working Group - Scalable Vector Graphics Working Group - XSL Working Group - Members of the Hypertext Coordination Group - the DOM Interest Group Last Call review period for this document extends until 14 September 2007. Please make sure you send your comments before 14 September 2007, as we will process your comments during our F2F the following week. Thanks, [1] http://lists.w3.org/Archives/Member/chairs/2007JulSep/0044.html [2] http://lists.w3.org/Archives/Member/chairs/2007JulSep/0078.html Thierry Michel, Team contact, SYMM Working Group. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Fwd: Implementing HTMLDocument on all Documents (detailed review of the DOM)
This is from the HTML group, but my first impression is that Simon is right. Unfortunately my other first impression is that nobody is currently really working on the relevant specs - is that true? cheers Chaals --- Forwarded message --- From: "Simon Pieters" <[EMAIL PROTECTED]> To: public-html <[EMAIL PROTECTED]> Cc: Subject: Implementing HTMLDocument on all Documents (detailed review of the DOM) Date: Tue, 21 Aug 2007 12:27:31 +0200 (This is part of my detailed review of the Document Object Model section.) The spec says about Documents: All Document objects (in user agents implementing this specification) must also implement the HTMLDocument interface, available using binding-specific methods. (This is the case whether or not the document in question is an HTML document or indeed whether it contains any HTML elements at all.) Document objects must also implement the document-level interface of any other namespaces found in the document that the UA supports. For example, if an HTML implementation also supports SVG, then the Document object must implement HTMLDocument and SVGDocument. We're not happy with implementing the HTMLDocument interface on all Document objects. It will affect all other types of documents and the naming of their members in the future, and any additions to HTMLDocument in the future becomes risky because it might break non-HTML documents. We'd rather have the members of HTMLDocument that are useful for all types of documents to be moved to the Document interface. This would probably be: * location * URL (also present in SVGDocument) * domain (also present in SVGDocument) * referrer (also present in SVGDocument) * cookie * lastModified * getElementsByClassName * innerHTML * activeElement * hasFocus * getSelection Furthermore, it might make sense to move the following members from HTMLElement to the Element interface: * getElementsByClassName * innerHTML * click() * focus() * blur() * scrollIntoView() ...because those might well be useful for any type of element. However, if we don't implement all supported interfaces on all Documents, the question instead becomes when do you implement a specific interface? Firefox decides on the MIME type, Opera decides on the root element's namespace, however I haven't yet checked how this works when e.g. replacing the root element or when creating new documents with DOM methods. This would need to be defined. I realise that moving members to Document and Element means changing DOM Core, so coordination with the WebAPI WG would be necessary. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Official results of memeber-only vote on Selectors API name combos
On Thu, 16 Aug 2007 19:56:59 +0200, Travis Leithead <[EMAIL PROTECTED]> wrote: Recently, a member-only vote was held to attempt (yet-again) to resolve general complaining, grumbling, etc., about the latest API names chosen for the Selectors API spec I suppose a vote was the only fair and equitable thing to do. Well, it seemed the last best hope to stop going around this forever. I suppose this thread is now open to hear what the standardistas think, but personally, I'd like to just put the voted name in, and get this spec done ;) Indeed. As chair, this is a formal announcement that the decision of the group is to use the name querySelector, and publish the last call draft with that name. (This gives the public a chance to raise any objection that they think will convince the group to open this debate and go round *AGAIN* - as W3C process requires - but means that within the group the issue is until then considered resolved by vote). As Bjoern Hoehrmann has previously noted, W3C's process aims to consensus, and that includes, in a case where a true consensus doesn't exist, going with the option that generates the least strong objections. This is fundamentally what disqualified getElementBySelctor since members of the group thought that the length was a serious problem. So there should shortly be a new draft with the name in it. Result highlights: querySelector()/querySelectorAll() scored 41 getElementBySelector()/getElementListBySelector() scored 43 The rest weren't really in the race, relatively speaking. Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [progress-events] and should be in sync
On Mon, 30 Jul 2007 11:52:47 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: Currently reads "The progress event". This is probably not intended. Also, the URI for "Latest W3C Working Draft" misses a dot between w3 and org. Oops. Both fixed - thanks. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [progress-events] stalled, lengthComputable, loadstart vs begin
On Thu, 26 Jul 2007 02:32:25 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Jul 25, 2007, at 6:49 AM, Anne van Kesteren wrote: * HTML 5 has an event called "stalled" that is dispatched after there are three seconds of no progress at all so you do not have to create your own timer scripts. 3 seconds of no progress might not be out of the ordinary depending on connection speed and distance to the host. This seems pretty arbitrary. I agree with Maciej on this one. I raised ISSUE-117 for it, but my proposal is that we do not adopt it (and that we point out to HTML-WG that 3 seconds is very arbitrary). This would be consistent with how we dealt with ISSUE-107... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [Network Communication API] Remarks on the current draft
On Thu, 26 Jul 2007 21:20:23 +0200, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: On Thu, 26 Jul 2007 21:04:05 +0200, Innovimax SARL <[EMAIL PROTECTED]> wrote: In http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html?rev=1.2&content-type=text/html;%20charset=iso-8859-1 [various typos and editorial errors] Thanks Mohamed, I will publish a new editors' draft in a few minutes with these corrections made... http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html?rev=1.3 cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [Network Communication API] Remarks on the current draft
On Thu, 26 Jul 2007 21:04:05 +0200, Innovimax SARL <[EMAIL PROTECTED]> wrote: In http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html?rev=1.2&content-type=text/html;%20charset=iso-8859-1 [various typos and editorial errors] Thanks Mohamed, I will publish a new editors' draft in a few minutes with these corrections made... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Network API draft...
Hi folks, a very incomplete editors' draft of a network api spec for socket-based connetions is now available http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html?rev=1.2&content-type=text/html;%20charset=iso-8859-1 Comments are welcome. It is known to have stuff missing, but don't be afraid to point out problems or errors. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Client fonts
João, Paul, are you interested in writing a more formal specification? And in doing the work of asking browser developers whether they have a need or desire for this, and are likely to implement it? cheers Chaals On Tue, 10 Jul 2007 00:42:46 +0100, João Eiras <[EMAIL PROTECTED]> wrote: There could be a collection, similar to navigator.plugins, which is navigator.fonts. ... That collection would be bound to a read only array in ecmascript, on which method like join() could be used to get a quick list of all fonts. This can be immensely useful for any rte editor which runs on a browser. Paul Libbrecht <[EMAIL PROTECTED]> escreveu: Le 9 juil. 07 à 21:55, João Eiras a écrit : Is there any proposed API to get information about installed fonts in the client at runtime ? something like navigator.plugins or navigator.mimeTypes I would largely second that! Even obtaining the metrics would be nice. Moreover, knowing if an installed font does have glyph-x or glyph-y (note: a unicode range availability is useless) should be. -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Selectors API Method Names
I have seen objections to every name proposed, which is a list even larger than that which Lachy considered originally. Given that we appear to have a working consensus on those proposed in the editor's draft, I suggest we publish that draft as a Public Working Draft, hoping to make it a Last Call draft 3 weeks later. (There will be a new call for consensus on the last call draft, if you really can't live with the names and have a better idea that can get consensus). Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: New staff contact - Doug Schepers
On Fri, 06 Jul 2007 14:57:58 +0200, Chris Lilley <[EMAIL PROTECTED]> wrote: Hello public-webapi, Since the departure of Dean Jackson, the WebAPI WG has been lacking a W3C staff contact. I have filled in where possible but have not had the time that the post needs. Doug Schepers, who you all know, is now the WebAPI staff contact. YAY!! Welcome Doug... so, this means that the person responsible for any delays in getting your element traversal spec published is... ... You! :) Hopefully we will have a lot more specs to publish in the next few months. Sorry, but I prefer that to not publishing. Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Selectors API Method Names
On Mon, 02 Jul 2007 20:17:40 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote: Hi- Maciej Stachowiak wrote: I don't have a strong objection either way, but I think the case against Lachy's original names (selectElement, etc) has been laid out more clearly than the case against cssQuery. I think selectorQuery (as suggested in follow-ups) would also be ok. I think that the chief problem with cssQuery*() for me is that it is rather confusing. Such a name would indicate functionality related to CSS (that is, something presentational or style-oriented), rather than the accident of a historical relationship. It totally fails the criteria of being functionally descriptive, which selectElement() meets (other merits notwithstanding); this is a point on which I think we can build consensus and compromise (and hopefully a speedy resolution). Similarly, with selectorQuery() (which is better), you lose the verby "action word" of the existing naming convention (getAByB); selectorQuery sounds more like a property than a method. Frankly, I'm not a fan of any of the present crop of names, but in the interest of keeping forward momentum, I least object to what we currently have, selectElement*(). Thank you Doug for so eloquently stating the details of my objection. As it happens, I agree with you that I would rather move forward with the consensus on selectElement*, if we establish that, than keep chasing round for new names. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Selectors API Method Names
On Thu, 28 Jun 2007 12:20:37 +0200, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Would others accept changing the methods to cssQuery() and cssQueryOne()? If this would achieve concensus, I'd be willing to use these names. Opera does not like the cssQuery names and prefers the names that were suggested in Lachy's draft. I recall strong objection to names which suggested this was about CSS in the past (but maybe it was only Anne objecting) on the basis that this isn't about CSS but selectors. So, Bjoern, Maciej, do you object to closing the issue with the names Lachy proposed in his draft, or are you just tossing in another idea in case it gets stronger consensus? cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Bindings spec ready for FPWD?
On Thu, 28 Jun 2007 04:05:13 +0200, Cameron McCormack <[EMAIL PROTECTED]> wrote: Hi everyone. I’ve filled in most of the interesting stuff for the Bindings spec, so I think it could do with some more review. "what Hixie said" :) Let's start a formal call for consensus. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [selectors-api] The Naming Debate
On Thu, 28 Jun 2007 07:17:41 +0200, Martijn <[EMAIL PROTECTED]> wrote: 2007/6/28, Doug Schepers <[EMAIL PROTECTED]>: Decisions get made all the time without informing the public list. The decision to create this spec in the first place was not a public decision. Most of the wording and functionality of the spec was the work of a small group of people. Only when an issue is raised does the debate start. Ok, thanks so that means it is normal to not inform people about decisions on the mailing list, right? No - although it happens. In this case, I didn't notice that the relevant message went to the member-only list (it should normally have gone to the public list) so didn't ask for it to be forwarded. And Lachy was brand new in the group at the time (April). I'm still not really too fond with the way this was handled, but I was under the impression that this was something that was voted upon. No. The working group doesn't generally work by vote. It aims to get consensus. Where there is a vote, it is a very fragile consensus, and people who weren't there to vote saying "hey, I have a real problem with this" can hold an issue open if they get some support. Sorry guys, I owe you, Lachlan and Charles (and probably more people) an apology... Not to me - I really should have made sure it was clear this issue was open. Well, the only natural name for me is getElementsBySelector and from what I read on irc from Lachlan, that is not going to happen, so there is nothing for me to debate, is there? If you really can't live with the names, and will ignore the spec and implement something else, then there is something to debate. I understand Jean-Yves' position and am extremely grateful to him and Sun for making this compromise. I think they are probably the ones with the strongest "substantial" case against it. Given that so many organisations have accepted the names proposed, I am hopeful that for the first time we can actually get a consensus. There are no good processes for resolving naming issues. Hence the call for consensus - if we can get it, then I am prepared to accept whatever names the consensus resolves on as being good enough. I don't love the current names. There are real problems with getElementsBySelector, get, and the various other proposals too. Finding a perfect name is, in my opinion, not much more likely than serving roast unicorn when you come for dinner - certainly not enough more likely to justify the effort beyond an attempt to reach consensus on *something*... So, sorry for the real communication failure, and I hope that you understand the process that got us here and can live with the names... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: [selectors-api] The Naming Debate
Hi guys, On Thu, 28 Jun 2007 01:03:26 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote: Martijn wrote: 2007/6/27, Doug Schepers <[EMAIL PROTECTED]>: I could not agree more with this sentiment. I know of no reason this issue should have been reopened, since there was no new evidence. But ultimately, it is not that important, which makes it all the more frustrating that it was reopened and effort was wasted. Yeah, this is a "me too". However, I do think this is important. So basically, I'm just really unhappy about this. Just posting a new proposal, without even mentioning about what was decided before, it's just very frustrating to me :( I feel being treated very unfairly :( I understand and sympathize with your frustration. But I'd ask you to consider the relative weight of the importance of the naming convention. In my view, it is far more important that this API be specified and implemented (and made available to authors) than to continue the debate about names. I am sorry. I suspect as chair that I failed to ensure that the issues were sufficiently clearly marked. It seemed to me that while the meeting which decided on names had reached a consensus among those present, we failed to establish a consensus on naming amongst the group at large. I therefore asked Lachy to try and do so. And I think he did an admirable job - as shown by the fact that for the first time I have not seen someone say "we really cannot live with these names and will block consensus if necessary". Whether they are perfect is, IMHO, immaterial, since the chances of that happening and of us still thinking they were perfect in 10 years time are vanshingly close to zero. That they are generally acceptable is what matters so we can publish a spec and people can get on with implementing and using it. ... If anything, I contend that reopening an issue that was closed by the group had the potential to block progress, and that the editor is fortunate that others have not sought to press the issue. That some people were not happy with the naming convention decided by the group was insufficient cause to reopen the issue, since an equal number of people are now unhappy with the new names; it's worth saying that consensus is not the same as unanimity, but is a process whereby people decide the manner in which they will cooperate toward a mutually beneficial end. I held the issue open because I had been told by people that the resolution we had reached for was in fact unacceptable. I am very happy (and grateful to all concerned) that so far the new proposal hasn't suffered that problem, and hopeful that this will allow us to proceed - less than six months (!) after all the substantive issues seem to have been settled... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: Status of algorithms
On Tue, 19 Jun 2007 23:39:41 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Jun 19, 2007, at 2:03 PM, Rotan Hanrahan wrote: I propose that the text that introduces an algorithm in the normative section be phrased something like the following (based on an idea suggested in Anne's most recent email to this list): "The value of the text response entity body MUST be determined by the agent as if it had run the following algorithm:" I think saying "as if" is good for total avoidance of ambiguity. I agree. I think that this proposed wording reads more clearly in english than the alternatives I have seen so far. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED]Catch up: Speed Dial http://opera.com
Re: requirements for a network spec
On Thu, 31 May 2007 02:24:43 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: Hi folks, we need to figure out what is really needed. A big requirement is security. It must not be possible to connect to an arbitrary port on the server and send anything, unless the server has explicitly stated that it allows so using some sort of white-listing mechanism. Yes. (Sorry, sent before I finished writing the mail). We need to clarify what normal security restrictions will be (so authors don't get surprised when they don't work) and why (so user agent developers understand why they should "very carefully consider" implementing these requirements...). The second requirement, I think, is a socket interface. Any more? cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Catch up: Speed Dial http://opera.com
Progress events being cancelable?
Hi, I propose to change the progress events to make them not cancelable. It has been pointed out that, for example, 'load' in DOM 3 is not cancelable, that the earlier SVG spec didn't have them cancelable, that there is no default action anyway, but if there is, such as informing the user that a transaction is in progress there are lots of drawbacks to canceling that and no clear benefit to justify keeping it cancelable. 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: ISSUE-106 and ISSUE-107 required frequency
On Tue, 24 Apr 2007 08:28:26 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > On Tue, 24 Apr 2007 06:36:30 +0200, Charles McCathieNevile > <[EMAIL PROTECTED]> wrote: >> Ian suggested that there should be a required frequency for progress >> events, and there was an issue over whether anything has to fire. The >> current draft requires that a loadstart fire, and some kind of event >> that signals an end-condition fire, but there is no requirement that a >> progress event fire in the middle, nor proposed frequency for this. >> >> I propose to leave the specification without further suggestions about >> frequency... > I would suggest that you explicitly mention that when the events are > dispatched is up to the specifications using the progress events, such as > the hypothetical XMLHttpRequest 2, the WHATWG HTML element > proposal, etc. "Specifications MAY make further requirements, such as a frequency for dispatching progress events. Specifications SHOULD not generally make those as recommendations rather than requirements (SHOULD, not MUST)." Or something like that? 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
ISSUE-106 and ISSUE-107 required frequency
Hi, Ian suggested that there should be a required frequency for progress events, and there was an issue over whether anything has to fire. The current draft requires that a loadstart fire, and some kind of event that signals an end-condition fire, but there is no requirement that a progress event fire in the middle, nor proposed frequency for this. I propose to leave the specification without further suggestions about frequency, and ths close these two issues http://www.w3.org/2005/06/tracker/webapi/issues/106 http://www.w3.org/2005/06/tracker/webapi/issues/107 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: ISSUE-108: Do progress total/loaded measure body content only, or include respose headers etc.?
On Mon, 29 Jan 2007 09:49:25 +0100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >> ISSUE-108: Do progress total/loaded measure body content only, or >> include respose headers etc.? >> >> http://www.w3.org/2005/06/tracker/webapi/issues/108 ... >> I think the sense of the group is that we don't include the >> transaction >> headers. I wonder if that is the right decision though. > > Given the standard UI use case, I think it is right. When you upload > or download a file, if you're displaying the size in bytes to the > user, they expect it to end up at the size of the file. Since we defer to the particular specification to say how to use this, and since progress should be applicable to things like fetching some stupidly big HEAD or a mail message, I think we should let specs taht say to use progress events decide how they do this. I propose we put a SHOULD in the section "using this with other specifications" saying that to meet common user expectations, header information should be left out in such cases as downloading a file via HTTP. 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
New member - Lachlan Hunt
Hi all, please welcome Lachlan Hunt to the working group as an invited expert. Another Australian, (is that a good thing?) he has also been involve in WHATWG and the new HTML Working Group. He has agreed to begin by taking on the task of wrapping up the Selectors API spec, so Anne can concentrate on finalising the XMLHttpRequest spec. So the spec will now have two co-editors. I look forward to hearing from the new one. (Reminder, last call for XHR closes on Monday, so if you think someone is still going to comment feel free to remind them to hurry up or ask for more time) 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: New draft of Progress events spec
On Thu, 29 Mar 2007 12:36:32 +0200, Jean-Yves Bitterlich <[EMAIL PROTECTED]> wrote: > Hi > Any reason why "TypeArg" is no more described for both initProgressEvent > methods ? A second-rate editor :) This section probably needs some reworking anyway, in order to make it clear that it just inherits from initEvent (noted as an issue in the spec). Will be fixed as soon as I copy/paste correctly... Cheers and thanks for picking this up. Chaals > Cheers, > Jean-Yves > > Charles McCathieNevile wrote: >> Hi folks, >> >> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.10 >> should have incorporated the substance of most changes I have said I would >> make. There is a bit of editorial scrubbing to be done (making references >> meet the W3C Manual of Style style, ...). >> >> I have added a section and example on how to use this in a spec essentially >> aiming to follow Maciej's proposal, made the conformance section try to >> cover different types of things that could conform in different ways, and >> tried to make the structure clearer. >> >> Comments welcome, as always. >> >> 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
New draft of Progress events spec
Hi folks, http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.10 should have incorporated the substance of most changes I have said I would make. There is a bit of editorial scrubbing to be done (making references meet the W3C Manual of Style style, ...). I have added a section and example on how to use this in a spec essentially aiming to follow Maciej's proposal, made the conformance section try to cover different types of things that could conform in different ways, and tried to make the structure clearer. Comments welcome, as always. 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: [XHR] Some clarifications
On Tue, 20 Mar 2007 10:46:00 -0400, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > > On Mon, 19 Mar 2007 15:11:38 +0100, denis sureau <[EMAIL PROTECTED]> > wrote: >> Thanks for the corrections and explanations. >> >> I'll translate the first sentence as that: >> >> 1) some object is created by a call to the constructor >> 2) it is created from a window >> 3) the window had an attribute XMLHttpRequest before this call >> 4) a window pointer is stored in the newly created object >> 5) it points out this window >> >> Is it right? > > Sort of. I tried to clarify this now: > > > http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#xmlhttprequest > > (This should hopefully also address your concern Charles. Raised in this > thread.) Yep, thanks. As an editorial amendment you could clarify how long it has to persist (not until the heat death of the universe, right?). But this seems clear to me now. 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
Fwd: Re: New progress event draft
Comments forwarded with permission... answers inline below --- Forwarded message --- From: "Ellen Siegel" <[EMAIL PROTECTED]> To: "Charles McCathieNevile" <[EMAIL PROTECTED]> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "Jean-Yves Bitterlich" <[EMAIL PROTECTED]> Subject: Re: New progress event draft Date: Mon, 19 Mar 2007 13:24:39 -0700 Here are some comments, and a few requests for clarifications, on the draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.9. initProgressEvent: Why are the comments on the initProgressEvent typeArg, cancelableArg, and canBubbleArg parameters written out instead of being "Refer to the event.initEventNS() method for a description of this parameter"? CMN: Because I copied and pasted. I don't mind either way (there is an issue listed, because there are arguments for keeping something in a whole spec as well as for making things work together by referring appropriately. I hadn't thought about since noting the issue, but it seems to me better to refer. (also, typo in the canBubbleArg description, it says "canceled" instead of "canBubble") CMN: I'll fix that. Can you clarify the possible values for the total parameter of initProgressEvent? Is this just a guesstimate, or must it either be accurate or zero? CMN: We can clarify it as seems reasonable. I would suggest that it should be accurate (with lengthComputable set to true) or zero (with lengthComputable set to false), but we have no way of knowing if a total is accurate until we have finished anyway. It is probably worth clarifying the constraint on the value of total (must be zero if lengthComputable is false) in the parameter description. How should implementation handle the case where totalArg specified in the initXX is negative? or is zero when lengthComputable is true? or is not zero when lengthComputable is false? CMN: Where lengthComputable is true and total is zero, it should be assumed that the thing is of zero length (a legitimate value). I am not sure how implementations should handle incorrect totals. If they notice the thing has finished successfully before the total size, I think they should just finish and ignore total. If they are not finished, and get more data after overrunning the declared total, they should just behave as if they don't know the total (unless it changes...). What is the expected behavior if initProgressEvent(NS)() is called with eventArg set to one of the begin, load, etc, but set canBubbleArg to true? Is it allowed or disallowed? (spec stats: These events /must not/ bubble, and /must/ be cancelable, but there is no guidance on how to deal with error cases) CMN: We can either change the must not to shold, or clamp the values for the event. I don't have a preference one way or the other. Any guidance on the expected behavior if the value provided for loadedArg is not positive, i.e., zero or negative? CMN: zero is a reasonable value. I suggest if it is not a non-negative integer we just clamp it to the closest number, or zero... In initProgressEventNS, Copy/Paste Typo: in the description of initProgressEventNS, it refers to initProgressEvent (no NS). CMN: will fix can namespaceURI be null? CMN: Yes, and it must be for the events we have defined. same comment as above: the description for canBubbleArg refers to "can be canceled" CMN: same response - will fix... (many of the comments from initProgressEvent also apply to initProgressEventNS, but I won't repeat them.) CMN: OK. I'll try to interpret intelligently... 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: [XHR] Some clarifications
On Sat, 17 Mar 2007 09:55:18 -0700, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > On Sat, 10 Mar 2007 12:01:52 +0100, denis sureau <[EMAIL PROTECTED]> >> 1) Some sentences need to be clarified: >> >> "When the constructor is invoked a pointer to the Window object which >> initially had XMLHttpRequest as an attribute of which the constructor was >> invoked must be stored on the newly created object, called the Window >> pointer." This is pretty tortuous. At the very least a few commas, to clarify the parsing, would be helpful. If I understand the grammar correctly (and I am not convinced that I do), I think this could be simplified as "When the constructor is evoked, a Window pointer must be stored on the newly created object. This is a pointer to the Window object within whose scope the constructor was invoked. (That's still kind of involved and unpleasant, but closer to something that is parseable.) 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: New Progress Events spec
On Wed, 14 Mar 2007 07:13:22 -0700, Gottfried Zimmermann <[EMAIL PROTECTED]> wrote: > > Charles, > > a couple of comments: > > (1) I think it would be useful to have (optional) information about time > included in the event, such as: > * elapsedTime > * estimatedTotalTime > * estimatedRemainingTime > > It seems that the originator of the ProgressEvent would have a better chance > to do a good estimation than the receiver, since it has probably more > knowledge about bandwidth, other traffic, etc. Estimating the total or remaining time is in general (e.g. for network operations, but also for compilation and similar extension use cases) just a guess based on what has happened so far, and it seems to make more sense to me to leave that to the consumer of the progress events. Do we need to explicitly attach time information to the progress events, or is it already available? (I need to sleep on this, or defer to someone who has the answer at their fingertips) > (2) The current spec should not be called "ProgressEvent", but rather > "DownloadProgressEvent". Its scope is restricted to a narrow use case. There is no reason it cannot be used for an upload, such as an HTTP PUT operation. Handling two-phase operations like HTTP POST is noted as a current issue (see below) with a proposed resolution. > However, have you thought about widening the scope, to include things like: > * Application timeouts (including the ability of AT to extend timeout > durations) Can you please expand on the use case for this and how it would work? > * Processing that requires a long time, e.g. compiling This has been considered. In principle I believe there is nothing that prevents such a process from being a source of progress events. The names of some of the events are chosen for backwards compatibility with existing operations. If it were clear how to measure the progress of some event other than in terms of byte transfers it would be worth considering how to do this, but I have not seen a clear proposal yet. > * Whole transactions (not just downloading data) There is an issue highlighted by the specific case of HTTP POST, where there is both an upload and a download component. Our proposal is to require that an operation which has progress in two phases provide two event targets for progress events. As far as I know, it is not a priori possible to know anything about the progress in advance of the actual operation, so there is not much point trying to anticipate that. 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
ElementTraversal spec draft
Hi folks, there is a new draft of the ElementTraversal specification: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html There are a few issues where the editors would like feedback: @@issue: should we add a childElements attribute that returns a list of elements? Advantages: lets authors use "for" looping structure; lets authors know the number of elements, in case they need to use that info in e.g. layout algorithms (var eachWidth = totalWidth / el.childElements.length;) Disadvantages: may add to the footprint If this is added, should the list be live or static? I am inclined to make this a static element list, a la the Selectors spec, since it is intended to be a lightweight interface Should there be Java and/or ECAMscript bindings in the spec? Anyway, for your enjoyment. Comments as specified in the Status of the Document section of the draft, please. 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: Review comments of Editors Draft of Progress Events
On Fri, 09 Mar 2007 15:08:46 +1100, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > > * Andrew Sledd wrote: >>initProgressEventNS description needs to make the statement >>that "the value of the namespaceURI argument must be null." > > I don't think so. The point of having the method is that this allows > others to re-use the interface for new event types, for example, for > proprietary browser extensions or for rarely used event types defined > by other organizations, neither of which should define event types in > no namespace without consulting the WebAPI Working Group. But for generating the actual events defined in the spec, they should have the null namespace, right? (Which is what Andy means) cheers -- 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: ISSUE-113: How do we represent HTTP POST?
On Thu, 08 Mar 2007 11:48:09 +1100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > On Mar 7, 2007, at 4:40 PM, Web APIs Issue Tracker wrote: >> POST can upload a pile of stuff, and then download a body. So there >> are >> two parts of the transaction whose progress would be useful to track. >> Further, these are in principle synchronous, and you don't know >> anything at all about the second part until you have finished the >> first >> one. > > The upload part would be represented via events on xhr.upload, if we > go with the recent proposal. The download would be events on the > XMLHttpRequest object itself. > >> Are there other problems of this nature? Is the best solution to make >> this the problem of XHR and similar specs that allow this >> situation, or >> to provide something in the progress spec? > > I think we decided to leave this to other specs to solve - any object > that does both upload and download should provide separate event > targets. Works for me. I will try to clarify in the next draft of the specification that other specifications should describe where and when to fire these events. I suppose it is also possible to write a spec for something that has multiple operations firing progress - say, downloading a page and all its linked resources. If someone wanted to do that. 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: WheelEvent alignment with MouseWheelEvent
On Thu, 08 Mar 2007 10:09:44 +1100, Andrew Sledd <[EMAIL PROTECTED]> wrote: > Chaals, > In conjunction with reviewing the ProgressEvents I've tried to review all of > the other events we have also spoken of referencing instead of specifying to > align specs. We've discussed this previously wrt WheelEvent (in svg) and > MouseWheelEvent in WebAPI. I don't find that event in the currently available > version of DOM 3 Events spec [1]. I have found this proposal [2] via an email > archive search. Can you find out what the status is and let us know? > Thanks, > Andy > > [1] http://www.w3.org/TR/DOM-Level-3-Events/ > [2] > http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/proposals/mousewheel.txt?content-type=text/plain Hi Andy, The current editor's draft of DOM 3 Events is at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html The proposal you referred to will be adopted. Our plan is to publish a new version of the draft as soon as we can get the editor and a staff contact together, which we hope will become a last call 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: Network API editor's draft
On Thu, 08 Mar 2007 06:27:50 +1100, Ian Hickson <[EMAIL PROTECTED]> wrote: > Note that the WHATWG version of this draft is in heavy flux; there are > hundreds of outstanding comments on it. Is the intent that this > specification replace the WHATWG version? Hmm. It is intended to be used by a similar audience. There is no compulsion on the WHAT-WG to remove their version at any given time, and maybe keeping it for now would motivate people to actually work on the spec. > (I am reluctant to just remove > the WHATWG part of the text because development on the last specification > for which I did that -- the Window spec -- has now ground to a halt and > left me with significant extra work, as I now have to move the definitions > back to HTML5 to deal with the more complicated cases which the Windows > spec says are out of scope.) Yes. I am sorry that the editors of that spec have slowed down. As you are aware, most spec editors are squeezing it in with other responsibilities, which sometimes has the unfortunate result that things don't move as fast as hoped. > Could you give an exact list of the changes between the WHATWG draft and > this one? (Ideally to the level of individual word and markup changes?) No, I can't, sorry. Perhaps Gorm has time to give some reasonable level of detail. The summary I can provide is "it is the TCP connection stuff out of the spec". 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: New Progress Events spec
On Thu, 08 Mar 2007 06:17:14 +1100, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Wed, 7 Mar 2007, Charles McCathieNevile wrote: >> > I think the event 'progressError' should be 'error' for backwards >> > compatibility. ... >> The spec doesn't mention 'error' or 'abort', but the ways to arrive at >> various end states are indeed not clearly distinguished. > > Sorry, s/error/progressError/, s/abort/progressCanceled/, and > s/load/progressComplete/ in the above comments; I was assuming the earlier > changes were accepted by the time I got to that comment. :-) OK. I'll stop being small-minded ;) (Those changes are in the new draft, BTW). >> > The spec says that the events must be cancelable but does not define >> > their default action. >> >> Right. Do you have a suggestion for a default action? Is there a reason >> we need one for everybody to implement? > > If there isn't one, it should just say so. Right, that works for me. >> > The following requirement both abuses RFC2119 terminology and makes no >> > sense from a conformance point of view: "This method may only be >> > called before the progress event has been dispatched via the >> > dispatchEvent method, though it may be called multiple times during >> > that phase if necessary." >> >> Could you explain what you mean by "makes no sense"? > > "may only" is not RFC2119-compatible grammar. Yep. > It also doesn't really make much sense to give conformance requirments on > when a method call can be called. It's not formally checkable, and we have > to define what happens when the requirement is violated anyway. So I am not sure what the use case is for the restriction, actually. I will try to find out, because I don't see what it achieves and will otherwise remove 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: [XHR] Unespected case
On Wed, 07 Mar 2007 19:07:51 +1100, Diego La Monica <[EMAIL PROTECTED]> wrote:
>
> Denis Sureau:
>
> The ping example seems not the best example of what a POST request usually is.
> I suggest a more useful request as following, instead:
>
> var xhr = new XMLHttpRequest();
> xhr.onreadystatechange=function()
> {
> if(xhr.readyState == 4)
> {
> alert("sent " + data);
> }
> };
>
> xhr.open("POST", "test.php", true);
> xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
> xhr.send("data=" + data);
>
>
> Denis Sureau - [EMAIL PROTECTED]
>
> Diego La Monica:
> What you write is completelly right Mr. Sureau, but in example 2 of
> paragraph 1.1 the working draft cites exactly:
> ***
> If you just want to ping the server with a message you could do something
> like:
>
> function ping(message) {
> var client = new XMLHttpRequest();
> client.open("POST", "/ping");
> client.send(message);
> }
> ***
> The above script is intended ( I suppose) as a System command but
> maybe i'm in wrong and is a simple POST message that does not wait for
> a respnse. In this case the word ping is not the right one is better
> (IMHO): "If you just want to make stay-up request to the server you
> could do something like: ".
>
> Dont you think so?
I think that using the word "ping" is a bad choice, since people who are used
to programmin expect it to be related to the ping command, rather than just
some local function for keep-alive or similar.
It seems to me that everybody is arguing that the example should do the same
thing, and the wording is causing the confusion...
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: New Progress Events spec
On Wed, 07 Mar 2007 17:45:25 +1100, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > > * Charles McCathieNevile wrote: >>To+: Bjoern. Bjoern, could you please review this specification >>for compatibility with DOM3 events? > > I've already made a number of comments, assuming the issues I pointed > out have been fixed, I do not currently have anything to add, but will > follow the draft as it progresses and comment as needed. Thank you. 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
Network API editor's draft
Hi folks. Thanks to Gorm and the WHATWG, we have http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html Comments and brickbats welcome 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: New Progress Events spec
To+: Bjoern. Bjoern, could you please review this specification for compatibility with DOM3 events? On Wed, 07 Mar 2007 13:19:46 +1100, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Wed, 7 Mar 2007, Charles McCathieNevile wrote: >> >> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html > > Early comments: Thanks for these. There is a new draft, incorporating some changes as discussed further below... > XmlHttpRequest should be XMLHttpRequest. Yup. > I disagree with "in general specifications should not specify that > progress events must occur". Me too, and removed it. > I don't think requiring these events causes > any backwards incompatibilities. The incompatibility is if someone in new > content assumes those events take place, but that will happen whether or > not a requirement uses a SHOULD requirement. In fact the entire > "Considerations for Backward Compatibility" section doesn't really make > any sense to me. Hmm. This draft marks a change in underlying assumptions. Having thought about it, I removed that section as it doesn't seem applicable to the new approach. > I think the event 'progressError' should be 'error' for backwards > compatibility. > > I think the event 'progressCanceled' should be 'abort' for backwards > compatibility. > > I think the event 'progressComplete' should be 'load' for backwards > compatibility'. All these are fine by me. > The spec doesn't say how to decide whether to fire 'error' or 'abort'. > > The spec implies that 'error' and 'abort' are not mutually exclusive with > 'load'. The spec doesn't mention 'error' or 'abort', but the ways to arrive at various end states are indeed not clearly distinguished. @@ToDo > The spec says that the events must be cancelable but does not define their > default action. Right. Do you have a suggestion for a default action? Is there a reason we need one for everybody to implement? > The initialisation methods for ProgressEvent are missing a > lengthComputableArg argument in the IDL. Whoops. Fixed. > The following requirement both abuses RFC2119 terminology and makes no > sense from a conformance point of view: "This method may only be called > before the progress event has been dispatched via the dispatchEvent > method, though it may be called multiple times during that phase if > necessary." Could you explain what you mean by "makes no sense"? Tightening up the use of RFC 2119 terminology is one thing, but the idea seems simple to me. > The specification is lacking requirements on user agents to set the event > attributes appropriately. Yep. > I would recommend changing the start of the "The ProgressEvent events" > section to more clearly indicate exactly what it is other specifications > are to do. As it stands I don't know that I'd be able to appropriately use > this specification to write another one that uses these events in a fully > well-defined and unambiguous way. That section could be significantly improved to make it easier and help it happen in an interoperable way. @@ToDo > Please have Bjoern review this specification for consistency with DOM3 > Events. I have as much control over Bjoern as you do, but this is explicitly cc'ed to him as a request that he takes a look. > The acknowledgements refer to the "WHATWG progress event proposal" as > being "invaluable in preparing this draft", but that seems unlikely since > there is no such proposal (the provided reference is to the > element, a UI widget). Yep. Fixed. 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: New Progress Events spec
On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote: > >> >> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/ >> Progress.html?rev=1.8 >> >> I would appreciate review, and in particular propose to publish >> this spec as a First Public Working Draft more or less in its >> current shape. > > I think it's fine for FPWD, other comments notwithstanding. Thanks, and thanks for the comments. I have made a new draft with some changes incorporated as discussed below... >> All other comments and criticisms are of course appreciated... > > I'll mostly try not to duplicate Ian's comments, though I agree with > many, but two stand out as worth repeating: > > - The terminal events should be load/abort/error rather than > progressComplete/progressCancel/progressError, for better backwards > compatibility. Yep, implemented now. > - The spec should not recommend that other specs make dispatch of > progress events optional. Specifications add new features over time, > and it doesn't make sense to require all new features to be optional. > Nothing about progress events makes them a special case for this. Agreed. > Other comments: > > - Conformance section -- the spec should define conformance classes. > I suggest "conforming implementation" and a conformance class for > specs that define use of progress events, much like the conformance > classes for the access-control spec. Yes, agree we should do something like this. @@To do > - "A progress event occurs when the user agent makes progress in some > network operation" -- perhaps this should be "data transfer > operation", as it might not necessarily be over a network. Yes, made this change. > - "User agents may dispatch one or more ProgressEvent of type > progress while a network operation is taking place." -- per my > earlier use cases document, I'd like to suggest requiring dispatching > at least one as the size is known (or definitely known to be unknown). Can you definitively know that the size is unknown? If the size is known to be zero, why have to fire the extra event? When the size is known, that knowledge is not necessarily accurate. For these reasons, but also because I am still a minimalist, I am not sure we should do this - so haven't yet made the change. What do others think? > - "These events must not bubble, and must be cancelable." -- I > suggest making these not cancelable, since there's no default action > to prevent. When discussed at the face to face - http://lists.w3.org/Archives/Public/public-webapi/2007Feb/att-0023/f2f5.html#item06 - the reason to make it cancelable was that while there is no defined default action, there might be a user agent default widget, and an application author may wish to cancel that and provide their own widget. Is there a better way to enable this than making the event cancelable? > - "readonly boolean lengthComputable" -- I suggest renaming this to > "totalKnown", to avoid arbitrary inconsistency with the name of the > "total" attribute, and because "known" is more accurate than > "computable". it began that way for compatibility with existing implementations, so I am waiting to hear what others say. 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
New Progress Events spec
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.8 I would appreciate review, and in particular propose to publish this spec as a First Public Working Draft more or less in its current shape. All other comments and criticisms are of course appreciated... 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: upload progress events
On Wed, 07 Mar 2007 08:37:15 +1100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > On Mar 6, 2007, at 1:21 PM, Boris Zbarsky wrote: >> That is would an implementation which dispatches the upload events >> both as "progress" events on xhr.upload and "uploadprogress" events >> on xhr be conformant to the specification. If so, that would allow >> existing code to continue working while allowing spec-compliant >> code to also work. >> >> I realize that there is an issue with providing non-standard ways >> to do what the standard allows in that authors might use code that >> works in one UA but not others. So I'm not even sure doing the >> above would be a good idea. But would it be allowed per the standard? > > I don't think any standard forbids dispatching additional events, > though you are correct that doing so creates interoperability risks. Agreed. There is nothing in the spec that says either way about events it doesn't actually define. 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: upload progress events
On Tue, 06 Mar 2007 15:46:57 +1100, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: > > On Tue, 06 Mar 2007 12:49:08 +1100, Maciej Stachowiak <[EMAIL PROTECTED]> > wrote: > >> Anne, Ian and I were discussing the fact that the Progress Events >> spec requires duplicates of every event for upload as well as >> download. This makes the spec a fair bit more complicated, especially >> if it ends up specifying a number of different progress events. >> >> As far as I know, this feature is only needed for XMLHttpRequest, >> since it's the only obvious element we can think of that does both >> upload and download, and where it's important to keep the two separate. >> >> However, we thought of a possible alternate design that might cover >> this case better. In brief, the idea is to use the same set of events >> for upload and download, but to provide a separate EventTarget >> attached to the XMLHttpRequest object, which is the target all the >> upload-related events; XHR itself only dispatches the download events. > ... >> This would require a change in XHR to adopt the Progress Events spec, >> but would considerably simplify Progress Events. Thoughts? > > Works for me... I am going to update the spec draft (tomorrow, since I have no overnight internet access), and will make it reflect this. By the by, I discussed the spec in the SVG group (which has people who have implemented progress events). They were happy with this idea and with the proposal that we go with the start and end events etc that Maciej has proposed, so that will also be in the next 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
Staff contact job at W3C
Hi folks, one of the key people in the WebAPI group is the staff contact - someone who works at W3C, makes sure we are connected, talks to the rest of the W3C Team, works in the group and on assorted other W3C stuff. Our contact, Dean Jackson, has worked at W3C for a number of years and is now running off to a new job. So W3C are looking for a replacement. The job ad is at http://www.w3.org/2007/01/HTML-WebAPI-position.html The advertising bit at the top is as follows: [[[ The World Wide Web Consortium (W3C) is looking for a new staff member to assist with W3C's work as team contact for two W3C Working Groups: HTML and WebAPI. This is an opportunity for a unique individual to be part of the team responsible for the design of next generation World Wide Web Technologies and to lead a variety of industry and user groups toward the development of technologies that enhance the functionality of the Web. The role of a W3C team contact is described in the W3C process. You will be associated with the Japanese W3C host Keio University, in Shonan Fujisawa, Japan, but you may choose to work remotely. You will have to travel often, to Working Group meetings or conferences in various international locations, as well as to the other W3C hosts, located at MIT in Boston, USA and at ERCIM in Sophia Antipolis, in the South of France. ]]] So, if you're interested in finding out what life is like inside W3C, and in fulfilling an important role in this group, have a look. (If you want to talk to someone who has worked there for 5 years, feel free to ask). 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: upload progress events
On Tue, 06 Mar 2007 12:49:08 +1100, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > Anne, Ian and I were discussing the fact that the Progress Events > spec requires duplicates of every event for upload as well as > download. This makes the spec a fair bit more complicated, especially > if it ends up specifying a number of different progress events. > > As far as I know, this feature is only needed for XMLHttpRequest, > since it's the only obvious element we can think of that does both > upload and download, and where it's important to keep the two separate. > > However, we thought of a possible alternate design that might cover > this case better. In brief, the idea is to use the same set of events > for upload and download, but to provide a separate EventTarget > attached to the XMLHttpRequest object, which is the target all the > upload-related events; XHR itself only dispatches the download events. ... > This would require a change in XHR to adopt the Progress Events spec, > but would considerably simplify Progress Events. Thoughts? Works for me... 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
