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

On Thu, Apr 17, 2014 at 8:21 AM, Domenic Denicola <> wrote:

>  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.

The first three sites I found transitions on use seconds: uses 0.1s, 0.5s (not 100ms, 500ms). uses 0.3s (not 300ms) uses 0.4s, 0.1s (not 400ms, 100ms)

Literally the first 3 transitions tutorials I found use seconds:

Do you have counter-examples?


>  ------------------------------
> From: Shane Stephens <>
> Sent: ‎4/‎16/‎2014 6:04 PM
> To: Douglas Stockwell <>;;
>; Rik Cabanier <>; Domenic Denicola<>;
> Paul Irish <>
> 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. 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:
> 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

Received on Wednesday, 16 April 2014 22:31:04 UTC