Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The Progress Events specification defines an abstract event interface that can be used for measuring progress; e.g. HTTP entity body transfers.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the 19 October 2010 W3C Working Draft of Progress Events. Please send comments to public-webapps@w3.org (archived) with [progress-events] at the start of the subject line.
This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
ProgressEvent
Interface
ProgressEvent
Types
This section is non-normative.
This specification defines an abstract event interface — ProgressEvent
— that can be used for measuring
progress. Other specifications use this specification for that purpose.
In this example XMLHttpRequest
, combined with
concepts defined in this specification, and the HTML progress
element are used together to display the process
of fetching a resource. [XHR] [HTML]
<!DOCTYPE html> <title>Waiting for Magical Unicorns</title> <progress id=p></progress> <script> var progressBar = document.getElementById("p"), client = new XMLHttpRequest() client.open("GET", "magical-unicorns") client.onprogress = function(pe) { if(pe.lengthComputable) { progressBar.max = pe.total progressBar.value = pe.loaded } } client.onloadend = function(pe) { progressBar.value = pe.loaded } client.send() </script>
Fully working code would of course be more elaborate and deal with more scenarios, such as network errors or the end user terminating the request.
Event
is defined by DOM Events. [DOMEvents]
Content-Length
and entity body are defined by HTTP. [HTTP]
Everything in this specification is normative except for diagrams, examples, notes and sections marked non-normative.
The key word must in this document is to be interpreted as described in RFC 2119. [RFC2119]
A user agent must also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification. [WebIDL]
User agents, Working Groups, and other interested parties are
strongly encouraged to discuss extensions on a relevant public
forum, preferably public-webapps@w3.org. If this is
for some reason not possible prefix the extension in some way and start
the prefix with an uppercase letter. E.g. if company Foo wants to add a
private method bar()
it could be named FooBar()
to prevent clashes with a potential future standardized
bar()
.
ProgressEvent
Interfaceinterface ProgressEvent : Event { readonly attribute boolean lengthComputable; readonly attribute unsigned long long loaded; readonly attribute unsigned long long total; void initProgressEvent(DOMString typeArg, boolean canBubbleArg, boolean cancelableArg, boolean lengthComputableArg, unsigned long long loadedArg, unsigned long long totalArg); };
The lengthComputable
must return true when the length of the progress is known, or false
otherwise.
The loaded
must return the
current state of progression.
The total
must return the
length of the progress, or zero if that is unknown.
The initProgressEvent
method must initialize the event in a manner analogous to the
similarly-named method in the DOM Events interfaces. [DOMEvents]
ProgressEvent
for HTTP Entity
BodiesWhen a specification says to dispatch an HTTP entity
body progress event named e it means that an event with
the name e, which does not bubble and is not cancelable, and
which uses the ProgressEvent
interface, is to be dispatched at the indicated object, with the remaining
members of the ProgressEvent
object set as follows, depending on the entity
body involved:
lengthComputable
True if the length is known, or false otherwise.
loaded
The number of entity body octets transferred.
total
The length of the entity body as given by
the Content-Length
header, or zero if
it is unknown.
ProgressEvent
for other contextsThis is left as an exercise for the editor of the specification that
introduces such a context. The editor is encouraged to define it in a way
consistent with this and other specifications using the ProgressEvent
interface.
ProgressEvent
For cross-origin requests some kind of opt-in, e.g. via Cross-Origin Resource Sharing has to happen before the events are dispatched as information would be revealed that cannot be obtained otherwise. [CORS]
ProgressEvent
TypesThis section is non-normative.
The suggested event types for use with the ProgressEvent
interface are summarized in the table below.
Specification editors are free to tune the details to their specific
scenarios, though are strongly encouraged to discuss their usage with the
W3C WebApps Working Group on public-webapps@w3.org to ensure
input from people familiar with the subject.
Name | Description | Times | When |
---|---|---|---|
loadstart
| Progress has begun. | Once. | First. |
progress
| In progress. | Zero or more. | After loadstart has been dispatched.
|
error
| Progression failed. | Zero or once. | After the last progress has been
dispatched, or after loadstart has been
dispatched if progress has not been dispatched.
|
abort
| Progression is terminated. | Zero or once. | |
load
| Progression is successful. | Zero or once. | |
loadend
| Progress has stopped. | Once. | After one of error , abort , or load has been
dispatched.
|
The error
, abort
, and load
event types are mutually exclusive.
Throughout the web platform the error
, abort
, and load
event types have
traditionally not had a default action and did not bubble so it is
suggested that for consistency all event types using the ProgressEvent
interface do not bubble and are not
cancelable.
Unless marked "Non-normative" these references are normative.
The editor would like to thank Aaron Leventhal, Alan Schepers, Alex Danilo, Andrew Emmons, Andrew Shellshear, Andy Sledd, Arthur Barstow, Björn Höhrmann, Boris Zbarsky, Cameron McCormack, Chris Lilley, David Håsäther, Doug Schepers, Ellen Siegel, Erik Dahlström, Garrett Smith, Gorm Eriksen, Gottfried Zimmermann, Ian Hickson, Jean-Claude Duford, Jean-Yves Bitterlich, Jim Ley, João Eiras, Kartikaya Gupta, Lisa Seeman, Maciej Stachowiak, Marcos Caceres, Michael Antony Puls, Nandini Ramani, Olli Pettay, Philip Jägenstedt, Rich Schwerdtfeger, Robert Sayre, Robin Berjon, Simon Pieters, Suresh Chitturi, and Travis Leithead for their contributions to this specification.
Special thanks to the SVG WG for drafting the original ProgressEvent
interface as part of the SVG
Micro DOM.
Thanks also to all those who have helped to improve this specification by sending suggestions and corrections. (Please, keep bugging us with your issues!)