[ProgressEvents] How to deal with compressed transfer encodings
Hi All, How should ProgressEvents deal with compressed transfer encodings? The problem is that the Content-Length header (if I understand things correctly) contains the encoded number of bytes, so we don't have access to the total number of bytes which will be exposed to the user until it's all downloaded. I can see several solutions: A) Set total to 0, and loaded to the number of decompressed bytes downloaded so far B) Set total to the contents of the Content-Length header and loaded the number of compressed bytes downloaded so far C) Like A, but also expose a percentage downloaded which is based on the compressed data B seems spec-wise the simplest, but at least gecko doesn't expose the compressed number of bytes downloaded, not sure about other HTTP libraries. It also has the downside that .loaded doesn't match .responseText.length C seems the most confusing for authors and the one I like the least. / Jonas
Re: [ProgressEvents] How to deal with compressed transfer encodings
On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@sicking.cc wrote: How should ProgressEvents deal with compressed transfer encodings? The problem is that the Content-Length header (if I understand things correctly) contains the encoded number of bytes, so we don't have access to the total number of bytes which will be exposed to the user until it's all downloaded. I can see several solutions: A) Set total to 0, and loaded to the number of decompressed bytes downloaded so far B) Set total to the contents of the Content-Length header and loaded the number of compressed bytes downloaded so far C) Like A, but also expose a percentage downloaded which is based on the compressed data B seems spec-wise the simplest, but at least gecko doesn't expose the compressed number of bytes downloaded, not sure about other HTTP libraries. It also has the downside that .loaded doesn't match .responseText.length When compression does not come into play they will only match for certain encoding / byte streams anyway. E.g. for a UTF-8 encoded character stream with characters that take up more than one byte they will not match. I think it should be B. C seems the most confusing for authors and the one I like the least. -- Anne van Kesteren http://annevankesteren.nl/
Re: [ProgressEvents] How to deal with compressed transfer encodings
* Anne van Kesteren wrote: On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@sicking.cc wrote: A) Set total to 0, and loaded to the number of decompressed bytes downloaded so far B) Set total to the contents of the Content-Length header and loaded the number of compressed bytes downloaded so far C) Like A, but also expose a percentage downloaded which is based on the compressed data When compression does not come into play they will only match for certain encoding / byte streams anyway. E.g. for a UTF-8 encoded character stream with characters that take up more than one byte they will not match. I think it should be B. That is what the draft already requires, if by compressed Jonas means you remove all transfer encodings but retain the content encodings, and you set .total to zero if the total length is not specified. (There are even more layers of compression to consider if you don't speak plain HTTP but, say, HTTP over TLS, since TLS has its own compression layer; that would be removed aswell under the current draft.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [ProgressEvents] How to deal with compressed transfer encodings
* Jonas Sicking wrote: How should ProgressEvents deal with compressed transfer encodings? The problem is that the Content-Length header (if I understand things correctly) contains the encoded number of bytes, so we don't have access to the total number of bytes which will be exposed to the user until it's all downloaded. I can see several solutions: Well, you have some information, you encode that using a media type, then you possibly encode that using a content encoding, and then you possibly encode that using a transfer encoding. HTTP uses transfer encodings for both message framing (chunked) and transformations, they are property of the transfer, while content encodings are part of the content. I would suggest to ask this question in terms of what .loaded should be when the download has finished. Should that be how much data has been recieved after the header, or how much data has been recieved except for framing information, or what the content developes thinks the size is, or how many bytes you will ultimately feed to, say, the HTML parser. That would be respectively the length of the message body, the length of the message body after removing the chunked transfer encoding, the length of the entity body, and the length of the entity body after removing content encodings. Note that you can apply compression as both content encoding and as transfer encoding, although the latter is only supported by good HTTP implementations, like Opera's, but hey, https://bugzilla.mozilla.org/show_bug.cgi?id=68517 isn't ten years old yet. I note that the draft actually defines this already, and I am pretty sure we discussed this already back in the day. B seems spec-wise the simplest, but at least gecko doesn't expose the compressed number of bytes downloaded, not sure about other HTTP libraries. It also has the downside that .loaded doesn't match .responseText.length Well, to get to the length of the content in terms of UTF-16 code units you have to remove transfer encodings, content encodings, and transcode from whatever character encoding the content is in to said UTF-16 code units, that's yet another layer and not a useful one in most cases here. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [ProgressEvents] How to deal with compressed transfer encodings
On 11/23/10 9:31 PM, Bjoern Hoehrmann wrote: That is what the draft already requires, if by compressed Jonas means you remove all transfer encodings but retain the content encodings This is actually ambiguous, since the near-total lack of server and UA support for Transfer-Encoding: gzip means that Content-Encoding: gzip is used to mean both transfer and content encoding (well, sometimes it also just means my server is misconfigured Apache, but I assume UAs already deal with this, by and large). -Boris
RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Arun, To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) Agreed. I have been thinking in terms of API design patterns and IMHO their target is to first document what we have in order to be able to foresee potential incompatibilities. That is why I shout early :) Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Thursday, November 19, 2009 12:55 AM To: Marcin Hanclik Cc: Anne van Kesteren; WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A* Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Nov 19, 2009, at 11:35 , Marcin Hanclik wrote: To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Actually, it's published (as a WD) and has a rather long background history of previous development in the File Upload spec. I think I'm not the only one who would like this particular baby to move forward rather fast. -- Robin Berjon - http://berjon.com/
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/
RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. I like the ProgressEvents spec and would keep it generic, i.e. change the names there to be generic and mandate their change in each spec that refer to ProgressEvents. PE is perfect to be a design pattern for asynchronous (and lengthy, more-than-one-shot, with-start-and-end, abortable and potentially erroneous) DAP APIs. In the firing grammar: progressgrammar = loadstart working (error | abort | load) loadend working = *( progress | (progress suspend progress) | (progress stalled progress) ) potentially rewritten to progressgrammar = start working (error | abort | done) end working = *( progress | (progress suspend progress) | (progress stalled progress) ) we would only need to change the working rule to accommodate various event firing scenarios. Thus under the same design pattern we could accommodate XHR, HTML5's media API, FileReader and any new DAP API. The event names could be related to the API for naming consistency, but firing model would be pre-defined were possible for design consistency. For example for directory walker (aka File Directory API or File API Level 3: Directories as proposed by Robin) we could have: directorywalkereventgrammar = start working (error | abort | done) end working = *( enterdir *file leavedir ) to be able to walk over e.g. 1M file entries in some FS. Any thoughts? I guess it may be over-engineering, but ... Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, November 18, 2009 10:31 AM To: a...@mozilla.com; Marcin Hanclik Cc: WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A*
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, ... What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. ... To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. Actually, this is a false etiology. The naming conventions are based on what people were already implementing (as Robin says, it is often easier to extend the definition than change the term, as linguistics shows us over a far longer history than the Web). If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. I don't actually. We have dumb names, because those are the terms we keep using... and the ones people are used to. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events Actually, if the argument to keep the names makes sense, then it makes sense, so there is not much point in trying to separate out a bunch of things with a new name. Experience has shown it doesn't usually work anyway. loadstart - start progress stalled suspend error I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. The author is the Working Group - and ergo all the members. I'm just the editor. 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: http://www.opera.com
[FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi, This is a set of architectural comments to the FileReader API, ProgressEvents and the design patterns for DAP. For DAP in [1] I propose the following consistency requirement (still [1] is a very early draft with bugs): All APIs MUST follow the same convention when handling callback functions (e.g. XHR / FileReaderAPI style with onreadystatechange, or ProgressEvents with EventTarget). There is currently discrepancy between XHR/FileReaderAPI and the ProgressEvents in terms of handling the same functionality differently. The ProgressEvents specification proposes is the event firing order [2], that could be summarized as a firing grammar (up to some lack of clarity around suspend and stalled events): progressgrammar = loadstart working (error | abort | load) loadend working = *( progress | (progress suspend progress) | (progress stalled progress) ) In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API. Therefore instead of (forgetting the above issue with the callback model for now): attribute Function onloadstart; attribute Function onprogress; attribute Function onload; attribute Function onabort; attribute Function onerror; attribute Function onloadend; we could have: attribute Function onreadstart; attribute Function onprogress; attribute Function onread; attribute Function onabort; attribute Function onerror; attribute Function onreadend; Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following: attribute Function onwritestart; attribute Function onprogress; attribute Function onwrite; attribute Function onabort; attribute Function onerror; attribute Function onwriteend; Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: loadstart - start progress stalled suspend error abort load - done loadend - end Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading. What to you think? Thanks, Marcin [1] http://dev.w3.org/cvsweb/~checkout~/2009/dap/design-patterns/Overview.html?rev=1.1content-type=text/html;%20charset=iso-8859-1 [2] http://dev.w3.org/2006/webapi/progress/Progress.html#Event1 Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API. Therefore instead of (forgetting the above issue with the callback model for now): attribute Function onloadstart; attribute Function onprogress; attribute Function onload; attribute Function onabort; attribute Function onerror; attribute Function onloadend; we could have: attribute Function onreadstart; attribute Function onprogress; attribute Function onread; attribute Function onabort; attribute Function onerror; attribute Function onreadend; What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. I'll note that 'onload' is very ubiquitous on the web platform, and has been for a while now. These progress events are also used within XHR. This kind of consistency is very desirable for developer convenience, and in my opinion, trumps the perfect name consideration. We've used consistency in naming before in this specification. Here are a few other examples: 1. INTIAL -- EMPTY, for closer name similarity to HTMLMediaElement's network status. 2. mediaType -- type, for closer name similarity with style.type 3. Error conditions like NOT_FOUND_ERR, SECURITY_ERR, and ABORT_ERR are used in DOMException codes and XHR's error codes respectively, including with the same error code. Essentially, the argument here is to reuse what developers are familiar with. *In particular* I'm swayed by the pervasive use of 'onload' on the web. However, I like your next point: Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following: attribute Function onwritestart; attribute Function onprogress; attribute Function onwrite; attribute Function onabort; attribute Function onerror; attribute Function onwriteend; To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) loadstart - start progress stalled suspend error abort load - done loadend - end Sure. On this question I'm less opinionated. Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading. I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0691.html
Re: [ProgressEvents]
Garrett Smith wrote: Are you asking: What if the loadend handler calls open() on the same connection in loadend? Right. When loadend is called, the actual completion event (abort | fail | load ) has not fired. Calling open should cause the previous connection to end. Jonas suggested that the corresponding event (abort | fail | load) should then fire unless e.preventDefault() is called. That is ok to me, even without the default behavior. This is just something to mention in the XHR2 spec. And the spec should handle also cases like calling abort() in loadend handler etc. Just curious: Why call open() again in loadend? I don't know. But I'm sure someone will write such script. -Olli
Re: [ProgressEvents]
Garrett Smith wrote: On Sun, Sep 7, 2008 at 8:47 AM, Erik Dahlström [EMAIL PROTECTED] wrote: Hello webapps wg, On behalf of the SVG WG I'd like to propose adding to the ProgressEvents spec[1] an event equivalent to the 'loadend' (previously known as 'SVGPostLoad') event currently defined in SVG Tiny 1.2 [2]. The 'loadend' event is dispatched by completion of a load, no matter if it was successful or not. In terms of the ProgressEvents spec the 'loadend' event would be dispatched following either of 'abort', 'load' or 'error', and there must be exactly one 'loadend' event dispatched. In the Event definitions table it would look like this: Name: loadend Description: The operation completed How often?: once When?: Must be dispatched last If the event were dispatched last, and there was a progress bar, plus an overlay, then the success handler would fire before the progress bar + overlay were hidden/removed. Please see also: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0537.html I would be in support of adding such an event. And I agree with Garrett that it makes more sense to dispatch it before the load/abort/error event is dispatched. In fact, we could even make the default behavior of the loadend event be dispatching one of the above three, thus allowing them to be canceled by calling .preventDefault on the loadend event. Would be interested to hear Ollis feedback given that he recently implemented progress events for XHR in firefox. / Jonas
loadend event Re: [ProgressEvents]
On Mon, 08 Sep 2008 04:25:42 -0500, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: On Sun, Sep 7, 2008 at 8:47 AM, Erik Dahlström [EMAIL PROTECTED] wrote: Hello webapps wg, On behalf of the SVG WG I'd like to propose adding to the ProgressEvents spec[1] an event equivalent to the 'loadend' (previously known as 'SVGPostLoad') event currently defined in SVG Tiny 1.2 [2]. The 'loadend' event is dispatched by completion of a load, no matter if it was successful or not. In terms of the ProgressEvents spec the 'loadend' event would be dispatched following either of 'abort', 'load' or 'error', and there must be exactly one 'loadend' event dispatched. In the Event definitions table it would look like this: Name: loadend Description: The operation completed How often?: once When?: Must be dispatched last If the event were dispatched last, and there was a progress bar, plus an overlay, then the success handler would fire before the progress bar + overlay were hidden/removed. Please see also: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0537.html I would be in support of adding such an event. And I agree with Garrett that it makes more sense to dispatch it before the load/abort/error event is dispatched. In fact, we could even make the default behavior of the loadend event be dispatching one of the above three, thus allowing them to be canceled by calling .preventDefault on the loadend event. Would be interested to hear Ollis feedback given that he recently implemented progress events for XHR in firefox. OK, I will put this into the draft (which I should post this week so we can try to publish it again. 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://www.opera.com
Re: [ProgressEvents]
On Mon, Sep 8, 2008 at 1:01 PM, Olli Pettay [EMAIL PROTECTED] wrote:
Jonas Sicking wrote:
Garrett Smith wrote:
On Sun, Sep 7, 2008 at 8:47 AM, Erik Dahlström [EMAIL PROTECTED] wrote:
Hello webapps wg,
On behalf of the SVG WG I'd like to propose adding to the ProgressEvents
spec[1] an event equivalent to the 'loadend' (previously known as
'SVGPostLoad') event currently defined in SVG Tiny 1.2 [2].
The 'loadend' event is dispatched by completion of a load, no matter if
it was successful or not. In terms of the ProgressEvents spec the 'loadend'
event would be dispatched following either of 'abort', 'load' or 'error',
and there must be exactly one 'loadend' event dispatched. In the Event
definitions table it would look like this:
Name: loadend
Description: The operation completed
How often?: once
When?: Must be dispatched last
If the event were dispatched last, and there was a progress bar, plus
an overlay, then the success handler would fire before the progress
bar + overlay were hidden/removed.
Please see also:
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0537.html
I would be in support of adding such an event. And I agree with Garrett
that it makes more sense to dispatch it before the load/abort/error event is
dispatched. In fact, we could even make the default behavior of the loadend
event be dispatching one of the above three, thus allowing them to be
canceled by calling .preventDefault on the loadend event.
Would be interested to hear Ollis feedback given that he recently
implemented progress events for XHR in firefox.
/ Jonas
Sounds good to me, though I don't have strong opinion whether
load/abort/error should be the default behavior for loadend. Maybe it is
better to not to add any default behaviors to PE.
The new event should be added to XHR2 too.
One thing to be clarified is that what should happen if loadend handler
restarts XHR - should load/abort/error still fire?
Are you asking: What if the loadend handler calls open() on the same
connection in loadend?
When loadend is called, the actual completion event (abort | fail
| load ) has not fired.
Calling open should cause the previous connection to end. Jonas
suggested that the corresponding event (abort | fail | load)
should then fire unless e.preventDefault() is called.
Just curious: Why call open() again in loadend?
I do not see a sequence of events for SVG:
http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#EventsPostload
However, I noticed this example:-
function imageLoadStart (evt) {
progressBar.setFloatTrait(width, 0);
var loadingAnimation = document.getElementById('loadingAnimation');
loadingAnimation.beginElement();
}
- attempts to reference progressBar without first declaring it. The
example also makes use of an 'ev' namespace that I can't see being
declared.
http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#events__ProgressEvent_total
A working example would be great.
Garrett
-Olli
Re: [ProgressEvents]
Hi Garrett.
Garrett Smith:
However, I noticed this example:-
function imageLoadStart (evt) {
progressBar.setFloatTrait(width, 0);
var loadingAnimation = document.getElementById('loadingAnimation');
loadingAnimation.beginElement();
}
- attempts to reference progressBar without first declaring it. The
example also makes use of an 'ev' namespace that I can't see being
declared.
http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#events__ProgressEvent_total
A working example would be great.
Thanks, fixed the namespace declaration and made the example complete.
http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/udom.idd.diff?r1=1.246r2=1.247
--
Cameron McCormack ≝ http://mcc.id.au/
[ProgressEvents]
Hello webapps wg, On behalf of the SVG WG I'd like to propose adding to the ProgressEvents spec[1] an event equivalent to the 'loadend' (previously known as 'SVGPostLoad') event currently defined in SVG Tiny 1.2 [2]. The 'loadend' event is dispatched by completion of a load, no matter if it was successful or not. In terms of the ProgressEvents spec the 'loadend' event would be dispatched following either of 'abort', 'load' or 'error', and there must be exactly one 'loadend' event dispatched. In the Event definitions table it would look like this: Name: loadend Description: The operation completed How often?: once When?: Must be dispatched last The SVG WG have aligned the other ProgressEvent event names[3], and have made changes to make these events compatible with the ProgressEvents 1.0 spec. Cheers /Erik, on behalf of the SVG WG, (ACTION-2159) [1] http://dev.w3.org/2006/webapi/progress/Progress.html [2] http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#EventsPostload [3] 'SVGPreLoad' - 'loadstart' and 'SVGProgress' - 'progress' -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
