W3C

Timing control for script-based animations

W3C Editor’s Draft 22 February 2011

Latest Editor’s Draft:
http://dvcs.w3.org/hg/anim-timing/tip/Overview.html
Latest Published Version:
Editors:
James Robinson, Google, Inc <jamesr@chromium.org>
Cameron McCormack, Mozilla Corporation <cam@mcc.id.au>

Abstract

This document defines an API web page authors can use to write script-based animations where the user agent is in control of limiting the update rate of the animation. The user agent is in a better position to determine the ideal animation rate based on whether the page is currently in a foreground or background tab, what the current load on the CPU is, and so on. Using this API should therefore result in more appropriate utilization of the CPU by the browser.

Status of this Document

This specification was written based on the mozRequestAnimationFrame feature implemented in Firefox.

Et cetera.

Table of Contents

1. Introduction

This section is informative.

Animations in web browsers come in two forms: native, declarative ones, such as the <animate> element in SVG, and those that are implemented in script. These script-based animations are most often performed by scheduling a callback using setTimeout or setInterval and making changes to the DOM to effect the animation in that callback.

A disadvantage of this approach is that the author of the animation script has no idea what the ideal frequency for updating their animation is. Instead, the easiest way forward for the author is to simply call setTimeout with a very small value, which in practice will be clamped to some minimum time like 10ms anyway. It likely won’t be the case that 100 updates per second are required for the animation, especially if the page is in a background tab or the browser window is minimized.

The API described in this document allows script authors to request the user agent schedule an animation frame update. The user agent is in a better position to determine how many frames per second to allocate to all of the animations running in the entire browser. If there are many animations active, the user agent can select a frame rate such that all of the animations will run as smoothly as possible. If the page is not currently visible, animations on that page can be throttled heavily so that they do not update often and thus consume little CPU power.

Example

Here is an example of using the API to write a script-based animation.

HTML
<!DOCTYPE html>
    <title>Script-based animation using requestAnimationFrame</title>
    <style>
    div { position: absolute; left: 10px; top: 10px;
      padding: 50px; background: crimson; color: white }
    </style>
    <script>
    function animate(time) {
      document.getElementById("animated").style.left = (time - animationStartTime)%500 + "px";
      window.requestAnimationFrame(animate, document.getElementById("animated"));
    }
    function start() {
      animationStartTime = Date.now();
      window.requestAnimationFrame(animate, document.getElementById("animated"));
    }
    </script>
    <div onclick="start()" id="animated">Click me!</div>

2. Conformance

Everything in this specification is normative except for diagrams, examples, notes and sections marked as being informative.

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels. [RFC2119]

The IDL fragment in section 4 of this specification MUST be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WEBIDL]

This specification defines a single conformance class:

conforming user agent
A user agent is considered to be a conforming user agent if it satisfies all of the MUST-, REQUIRED- and SHALL-level criteria in this specification. A conforming user agent MUST also be a conforming implementation of the IDL fragment in section 4 of this specification, as described in the Web IDL specification. [WEBIDL]

This specification references interfaces and types from a number of other specifications:

3. Definitions

The native animations in a Document include all of the following, if the user agent implements the relevant specification:

A native animation is considered to be active if the current time is between the animation’s start and end time (inclusive), or if it has ended but has not yet been sampled for the frame immediately after its cessation.

As distinct from native animations, a script-based animation is one that is implemented manually by an author by continually manipulating the DOM.

4. The WindowAnimationTiming interface

The WindowAnimationTiming interface is used to expose the requestAnimationFrame operation on the Window object. In the definition of requestAnimationFrame below, references to the Document object are to be taken to be references to the Window object’s active document. [HTML5]

Associated with every Document is a animation frame request callback list, which is a list of FrameRequestCallback objects and which initially is an empty list.

A Document is said to have active animations whenever it has a non-empty animation frame request callback list.

[Supplemental, NoInterfaceObject]
interface WindowAnimationTiming {
  long requestAnimationFrame(in FrameRequestCallback callback, in Element element);
  void cancelRequestAnimationFrame(in long handle);
};

Window implements WindowAnimationTiming;

[Callback, NoInterfaceObject]
interface FrameRequestCallback {
  void sample(in DOMTimeStamp time);
};

The requestAnimationFrame method is used to signal to the user agent that a script-based animation needs to be resampled. When requestAnimationFrame(callback) is called, the user agent MUST schedule a script-based animation resampling by appending callback to the end of L. requestAnimationFrame returns a user-agent-defined integer handle to identify this callback.

Note

requestAnimationFrame only schedules a single update to the script-based animation. If subsequent animation frames are needed, then requestAnimationFrame will need to be called again from within the callback.

When cancelRequestAnimationFrame method is called, the user agent MUST remove the callback associated with handle from L, if such a callback exists.

While a Document has active animations, the user agent MUST continually sample all animations. To sample all animations, the following steps are performed:

  1. Let t be the result of getting the next sample time of the Document.
  2. Let time be t expressed as the number of milliseconds since 1970-01-01T00:00:00Z.
  3. Let list be a copy of the Document’s animation frame request callback list. list will be empty if no script-based animations have been scheduled.
  4. Perform the steps defined in the invoke callbacks algorithm with parameters list and time

The invoke callbacks algorithm:

  1. For each entry callback in list, in order:
    1. If the callback has not been cancelled:
      1. If the callback was specified with an element and the element may be visible:
        1. Call the requestAnimationFrame operation of callback with time as the argument.
        2. If calling the operation resulted in an exception being thrown, then catch that exception and ignore it.
        3. Return to the beginning of the invoke callbacks algorithm
  2. If no callbacks were fired in this iteration of the invocation algorithm, terminate these steps.
Note

The purpose of this algorithm is to ensure that the callback for all potentially visible elements is invoked for a frame even if a side effect of invoking one callback changes the visibility of an element associated with another callback.

An element may be visible if the user agent determines that some portion of the element may be displayed.

Note
Determining visibility precisely in all cases for all possible rendering models is a difficult task. If in doubt, it is always safe to assume that an element may be visible, while it is not safe to declare that an element is not visible if it might be.

5. Acknowledgements

This section is informative.

The editor would like to thank the following people for contributing to this specification: some people here.

A. References

A.1. Normative references

[CSS3-ANIMATIONS]
CSS Animations Module Level 3. D. Jackson, D. Hyatt and C. Marrin, Editors. World Wide Web Consortium, March 2009. Work in progress. Available at http://www.w3.org/TR/2009/WD-css3-animations-20090320.
[CSS3-TRANSITIONS]
CSS Transitions Module Level 3. D. Jackson, D. Hyatt, C. Marrin and L. D. Baron, Editors. World Wide Web Consortium, December 2009. Work in progress. Available at http://www.w3.org/TR/2009/WD-css3-transitions-20091201.
[DOM3CORE]
Document Object Model (DOM) Level 3 Core Specification. A. Le Hors, et al., Editors. World Wide Web Consortium, April 2004. Available at http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/.
[HTML5]
HTML5. I. Hickson, Editor. World Wide Web Consortium, June 2010. Available at http://www.w3.org/TR/2010/WD-html5-20100624/.
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. Available at http://www.ietf.org/rfc/rfc2119.
[SVG11]
Scalable Vector Graphics (SVG) 1.1 (Second Edition). E. Dahlström, et al., Editors. World Wide Web Consortium, June 2010. Work in progress. Available at http://www.w3.org/TR/2010/WD-SVG11-20100622/.
[WEBIDL]
Web IDL. C. McCormack, Editor. World Wide Web Consortium, October 2010. Available at http://www.w3.org/TR/2010/WD-WebIDL-20101021/.

A.2. Informative references

There are no informative references.

B. Changes

The following is a list of substantial changes to the document on each publication.

1 January 20xx – FPWD
  • Initial publication.