Abstract
The Progress Events specification defines an event interface that can
be used for measuring progress; e.g. HTTP entity body transfers. This
specification is primarily meant to be used by other specifications.
Status of this Document
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
https://www.w3.org/TR/.
As anticipated by the Memorandum of Understanding Between W3C and WHATWG, this specification is a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification.
This specification was a part of
the upstream WHATWG version
of the XMLHttpRequest Living Specification.
For purposes of the W3C Patent Policy, this Superseded Recommendation has the same status as an active Recommendation;
it retains licensing commitments and remains available as a reference for old -- and possibly still deployed --
implementations, but is not recommended for future implementation.
New implementations should follow the
ProgressEvent interface
of the XMLHttpRequest Living Standard.
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.
Table of Contents
- 1 Introduction
- 2 Conformance
- 3 Terminology
- 4 Interface
ProgressEvent
- 4.1 Firing events using the
ProgressEvent interface for HTTP
- 4.2 Firing events using the
ProgressEvent interface for other contexts
- 4.3 Suggested names for events using the
ProgressEvent interface
- 4.4 Security Considerations
- References
- Acknowledgments
1 Introduction
This section is non-normative.
This specification defines an 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.
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]
A user agent must also be a conforming implementation of DOM4's Events and Event constructor.
[DOM]
3 Terminology
Terminology used in this specification is from DOM4 and HTTP.
[DOM]
[HTTP]
4 Interface ProgressEvent
[Constructor(DOMString type, optional ProgressEventInit eventInitDict)]
interface ProgressEvent : Event {
readonly attribute boolean lengthComputable;
readonly attribute unsigned long long loaded;
readonly attribute unsigned long long total;
};
dictionary ProgressEventInit : EventInit {
boolean lengthComputable;
unsigned long long loaded;
unsigned long long total;
};
Events using
the ProgressEvent interface indicate some kind of
progression.
The
lengthComputable
attribute must return the value it was initialized to. When an
event is created
the attribute must be initialized to false.
The
loaded and
total
attributes must return the value they were initialized to. When an
event is created
the attributes must be initialized to 0.
4.1 Firing events using the ProgressEvent interface for HTTP
To
fire a progress event named e
means to
fire an event named e
with an event
using the ProgressEvent interface that also meets these
conditions:
This definition can be used by other specifications. XMLHttpRequest does this for instance.
[XHR]
4.2 Firing events using the ProgressEvent interface for other contexts
This 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 that utilize
events using the
ProgressEvent interface.
4.3 Suggested names for events using the ProgressEvent interface
This section is non-normative.
The suggested
type attribute
values for use with
events using 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.
type attribute value
| 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 their
bubbles and
cancelable
attributes initialized to false, so it is suggested that for consistency
all events using
the ProgressEvent interface do the same.
4.4 Security Considerations
For cross-origin requests some kind of opt-in, e.g.
Cross-Origin Resource Sharing, has to be used before
events using the
ProgressEvent interface are
dispatched
as information (e.g. size) would be revealed that cannot be obtained
otherwise. [CORS]
References
- [CORS]
- (Non-normative) Cross-Origin Resource Sharing, Anne van Kesteren. W3C.
- [DOM]
- DOM, Anne van Kesteren, Aryeh Gregor, Ms2ger et al.. W3C.
- [HTML]
- (Non-normative) HTML, Robin Berjon, Travis Leithead, Erika Doyle Navara et al.. W3C.
- [HTTP]
- Hypertext Transfer Protocol -- HTTP/1.1, Roy Fielding, James Gettys, Jeffrey Mogul et al.. IETF.
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
- [WEBIDL]
- Web IDL, Cameron McCormack. W3C.
- [XHR]
- (Non-normative) XMLHttpRequest, Julian Aubourg, Jungkee Song, Hallvord R. M. Steen et al.. W3C.
Acknowledgments
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,
Cyril Concolato,
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,
Ms2ger,
Nandini Ramani,
Olli Pettay,
Philip Jägenstedt,
Ralph Swick,
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!)