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