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

On Thu, Apr 17, 2014 at 10:42 AM, Brian Birtles <bbirtles@mozilla.com>wrote:

> (2014/04/17 8:39), Michael Mullany wrote:
>
>> Tab,
>>
>> I think this is a JavaScript / CSS cultural divide. I have rarely seen
>> ms used in CSS questions on StackOverflow or in almost any Codepen
>> example. On the other hand, I think JavaScript folks think in ms.
>>
>
> I think you're right. Paul's survey and GitHub search seem to confirm this
> pattern.
>
> My inclination at the moment is to make raw numbers in Web Animations
> represent ms.
>

My inclination is the opposite. I stand by the group's decision to choose
seconds for this API.

Choice of milliseconds for setTimeout was based on a desire to represent
time as an integer value, and a feeling that millisecond resolution was
'close enough'. It is true that this choice has then been used as a basis
for the design of many (but not all) JS apis dealing with animation, but it
was not a choice made with regard for developer ergonomics or correctness.

Conversely, the vast majority of other media APIs (both in JavaScript and
on other platforms) have adopted seconds as the more natural unit.

Ultimately this comes down to the following decision: is it more important
to align with JavaScript (as this is a JavaScript API), or more important
to align with the current practice of those who author Animations (as an
API that generates Animations)? The decision is complicated somewhat by the
fact that there is no clear consensus within JavaScript.

I thought we could possibly make the TimingInput dictionary's 'duration'
> member be a union type "(DOMString or double)" but they're not
> distinguishable right?
>
> Suppose we find a way to allow "2s", "2000ms" or 2000 (=milliseconds) for
> "duration", we'd have to apply the same treatment to "delay", "endDelay",
> and "iterationStart". And we'd have to also do the same for the Timing
> interface later and define behavior so that when setting
> animation.timing.duration = "2s" we automatically convert it to 2000 (so
> that whenever you *read* animation.timing.duration you get the same thing
> and didn't have to test its type). And then there's AnimationPlayer too.
> It's possible, but it seems preferable if we can just settle on seconds or
> milliseconds.
>
> I'm not sure how to resolve this but I think Shane has some ideas for
> polling.


We currently have two polls reaching out to different sections of the Web
Developer community. I'll report on results once we have them.

 I personally doubt that many CSS folks will adopt Web Animations (it has
>> always seemed to me a very complicated spec to understand), so perhaps
>> ms makes sense for the audience that will use it.
>>
>
> It's a massive spec. I think we'll end up carving out a subset as level 1.
> It would help if we can get tool support to achieve this.
>
> Best regards,
>
> Brian
>

Cheers,
    Shane