Re: Processing model for the first argument of Animatable.animate is not well defined

Hi Boris,

Thanks for your feedback!

On Wed, Apr 16, 2014 at 3:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> There are actually several issues here:
>
> 1)  (AnimationEffect or EffectCallback or OneOrMoreKeyframes) is not a
> valid WebIDL union, because EffectCallback is a callback type an
> OneOrMoreKeyframes is a union of a dictionary type (ish) and a sequence
> type.  But callbacks and dictionaries are not distinguishable, so can't be
> used in the same union.
>

That is a shame. As you suggest, we can switch the first argument to
"object". Another option is to support only sequences of keyframes, not
individual keyframes:
(AnimationEffect or EffectCallback or sequence<Keyframe>)


> 2)  The "KeyFrame" not-really-a-dictionary thing doesn't have a clear
> processing model defined.  Specifically:
>   a) In section 5.14.6 step 7 there is no definition of what "Iterate
>      over the properties of keyframe input." means.  There are several
>      possible definitions, which lead to different observable behavior.
>

I think you're talking about reading values with side-effects (e.g. off
objects that have non-const getters) here? Step 9 defines a lexicographic
ordering for animation properties - we could ensure that this lexicographic
ordering is used when iterating over keyframe input as well. This is the
natural thing to do as it avoids multiple implementation passes over the
input, so it's unlikely that implementations would diverge without really
trying to, but it makes sense to specify this more firmly.


>   b) Step 7 talks about setting properties of keyframe input, which
>      doesn't make sense.  Does it mean to talk about setting properties
>      of keyframe result?


Thanks for picking that up. You are correct.


>   c) Nothing seems to define _when_ the algorithm of section 5.14.6 is
>     invoked.  For example, when animate() is called with two arguments,
>     the first of which is a sequence, is that algorithm performed on
>     elements of the sequence before the second argument is coerced to
>     (double or TimingInput)?  This matters, because that coercion can
>     have side-effects, as can the algorithm in question, and the
>     ordering needs to be defined.
>

Again we should specify the 'natural' thing to do (i.e. process input
arguments in order).


> It seems like what's really wanted here is to define the first argument of
> animate() to be "object?" and then in the prose for the method define the
> actual processing model for determining which sort of thing it should be.
>  That would solve problems (1) and (2c) above.  (2a) and (2b) would need to
> be addressed separately...


Thanks again for your comments. I'd like to hear from Brian, but IMHO I
think our actions should be:
(1) switch the input to element.animate (and the Animation constructor)
from a big union to 'object'
(2) add a normative section to 5.9.4 defining how to convert from 'object'
to AnimationEffect, EffectCallback or OneOrMoreKeyframes.
(3) Explicitly state that the ordering in Step 7 matches the lexicographic
ordering in Step 9 of 5.14.6
(4) Explicitly state (in the new normative part of section 5.9.4) that
5.14.16 runs before coersion of the second argument to (double or
TimingInput).

Section 5.10.1 already indicates that element.animate creates a new
Animation object, so I think tightening up the Animation constructor should
be sufficient.

Cheers,
    -Shane


>
> -Boris
>
>