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

Hello :)

Here's just a web dev reaction to this discussion.

In my daily job, I'm used to use both second and millisecond to build
animation. Most of the time, I use second when using CSS where I use
milliseconds when I have to deal with JavaScript (mainly because of the
setTimeout function and the fact that timestamps created with the Date
object are expressed in milliseconds). Both are okay with a clear drawback:
milliseconds suck to express long time frame and seconds suck to express
very short time frame.

What would be really awesome would be the following:

   - If a time value must be expressed with a number, it would be better if
   it were milliseconds as JS developers often manipulate timestamps through
   the "+new Date" expression.
   - However, it is true that CSS and SVG people are more used of the
   second unit (but they also use millisecond, especially for short
   transition). To suits their own use cases, it would be nice if a time value
   could be also expressed as a time string, including a number value followed
   by a unit as it is always the case for CSS values. That way, both web
   developer and designer could easily use the web animation API.
   - Of course to express a moment in time, being able to directly use a
   Date object would also be a huge plus for JS developers.


Best
Jeremie


2014-04-17 0:04 GMT+02:00 Shane Stephens <shans@google.com>:

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



-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>