RE: Units of time in Web Animations [was: Intent to Ship: Element.animate]

Regardless of spec examples, all of the real-world CSS transition and animation code I've seen uses the ms unit, not the s one. I don't think CSS provides any guidance here.
________________________________
From: Shane Stephens<mailto:shans@google.com>
Sent: ‎4/‎16/‎2014 6:04 PM
To: Douglas Stockwell<mailto:dstockwell@google.com>; public-fx@w3.org<mailto:public-fx@w3.org>; bbirtles@mozilla.com<mailto:bbirtles@mozilla.com>; Rik Cabanier<mailto:cabanier@gmail.com>; Domenic Denicola<mailto:domenic@domenicdenicola.com>; Paul Irish<mailto:paulirish@google.com>
Subject: Units of time in Web Animations [was: Intent to Ship: Element.animate]

+public-fx

We welcome discussion on this topic, but I encourage everybody to consider the full range of data before making a case based off a single data point.

Existing APIs and tools
-------------------------------
(1) Although units are specified, CSS Animations, CSS Transitions and SVG Animations all strongly default to seconds units (not a single example in any specification presents an animation with 'ms'). More than 50% of page views involve one of these APIs, which strongly suggests that the default animation unit on the web today is seconds, not milliseconds.
(2) The JavaScript exposures of CSS Animations, CSS Transitions and SVG Animations (e.g. events, ElementTimeControl) all treat inputs and outputs as time in seconds.
(3) Native media APIs (Web Audio, Media Elements) use seconds
(4) some third-party animations libraries (e.g. Core Animations, WPF [kinda], GSAP, animo) use seconds
(5) industry tools like Adobe AfterEffects tend to report time values in seconds

We need to balance this against:
(1) Native platform APIs dealing with time (e.g. performance.now) return milliseconds
(2) requestAnimationFrame reports time in milliseconds
(3) some other third-party animations libraries (e.g. jQuery, d3, tween, collie, minified, rekapi) use milliseconds. Note that I was unable to find examples of animation libraries outside of the realm of JavaScript that use milliseconds.

Interoperability
--------------------
Our mandate is to unify CSS and SVG. I think this induces a pretty clear requirement to keep using the unit of time measurement common to these technologies, rather than changing it.

More than 50% of all page views (source: http://www.chromestatus.com/metrics/css/popularity) involve CSS Animations or Transitions. I strongly doubt that the total usage count of all third-party animations libraries added together comes close to this. Again, a strong indicator that the most common animation time unit out there is seconds, not milliseconds.

Outside of the web, the industry overwhelmingly prefers seconds, from what I can tell.

Balancing this, most (but not all) JavaScript that deals with time does so in milliseconds (exceptions: events from CSS and SVG, some animation libraries, any code dealing with media or audio).

"Correctness"
-------------------
In the absence of pre-existing libraries, tools, or APIs, what would we pick?

I would argue that it is uncommon if not rare to require animations on a millisecond time scale, but that it is extremely common to require animations on a second time scale. Even the range of ~0.1s - 1s is quite naturally expressed as a fraction of a second.

Humans have no intuitive understanding of the length of a millisecond, other than as a tiny portion of the much more natural unit of seconds.

Cheers,
    -Shane