Progress Events

W3C Proposed Recommendation 12 December 2013

This Version:
Latest Version:
Latest Editor Draft:
Previous Versions:
Anne van Kesteren, Mozilla (Upstream WHATWG version)
Charles McCathieNevile, Yandex (Authored until 2010)
송정기 (Jungkee Song), Samsung Electronics


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 http://www.w3.org/TR/.

This specification is also a part of the upstream WHATWG version of the XMLHttpRequest Living Specification.

This specification is the 12 December 2013 W3C Proposed Recommendation of Progres Events. The W3C's Web Applications Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track. This group created an Implementation Report that shows the Progress Event Candidate Recommendation's exit critera has been met.

This is the W3C Proposed Recommendation of "Progress Events". W3C publishes a technical report as a Proposed Recommendation to indicate that the document is a mature technical report that has received wide review for technical soundness and implementability and to request final endorsement from the W3C Advisory Committee. Proposed Recommendation status is described in section 7.1.1 of the Process Document.

The W3C Membership and other interested parties are invited to review the document and send comments to public-webapps@w3.org (archived) with [ProgressEvents] at the start of the subject line. Advisory Committee Representatives should consult their WBS questionnaires. The deadline for review and comments is 17 January 2014.

By publishing this Proposed Recommendation, W3C expects that the functionality specified in this Proposed Recommendation will not be affected by changes to DOM4 or Web IDL as those specifications proceed to Recommendation.

Publication as a Proposed Recommendation 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.

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. 1 Introduction
  2. 2 Conformance
  3. 3 Terminology
  4. 4 Interface ProgressEvent
    1. 4.1 Firing events using the ProgressEvent interface for HTTP
    2. 4.2 Firing events using the ProgressEvent interface for other contexts
    3. 4.3 Suggested names for events using the ProgressEvent interface
    4. 4.4 Security Considerations
  5. References
  6. 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>
  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;

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.

2 Conformance

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]


(Non-normative) Cross-Origin Resource Sharing, Anne van Kesteren. W3C.
DOM, Anne van Kesteren, Aryeh Gregor, Ms2ger et al.. W3C.
(Non-normative) HTML, Robin Berjon, Travis Leithead, Erika Doyle Navara et al.. W3C.
Hypertext Transfer Protocol -- HTTP/1.1, Roy Fielding, James Gettys, Jeffrey Mogul et al.. IETF.
Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
Web IDL, Cameron McCormack. W3C.
(Non-normative) XMLHttpRequest, Julian Aubourg, Jungkee Song, Hallvord R. M. Steen et al.. W3C.


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!)