- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 09 May 2007 14:31:43 +0300
- CC: web API <public-webapi@w3.org>
Maciej Stachowiak wrote: > > Hi everyone, > > 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. What the upload event target would look like? I think there should be some way to get from upload to the xhr object to identify what xhr the upload object is related to. So maybe something like interface XMLHttpEventTarget : EventTarget { attribute EventListener onload; attribute EventListener onerror; attribute EventListener onprogress; attribute EventListener onabort; attribute EventListener onreadystatechange; } interface XMLHttpRequest : XMLHttpEventTarget { ... readonly attribute XMLHttpUpload upload; } interface XMLHttpUpload : XMLHttpEventTarget { readonly attribute XMLHttpRequest request; } This is probably something to be defined in XHR2, so probably for gecko it is better to keep dispatching "uploadprogress" to xhr. -Olli
Received on Wednesday, 9 May 2007 11:31:58 UTC