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

On 4/16/14 2:18 AM, Shane Stephens wrote:
> 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>)

Callbacks and sequences are also not distinguishable in WebIDL as 
currently specified, though there have been some proposals that might 
change that.

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

No, that's not what I'm talking about.  I'm talking about the fact that 
this could be talking about doing Object.keys(keyframe input) or 
Object.getOwnPropertyNames(keyframe input) or the equivalent of a 
for...in loop, or possibly something else.  Those all have observably 
different behavior.

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

Just to make sur I understand: right now the model in 5.14.6 step 7 is 
that you get the list of property names from keyframe input, then walk 
that list and do something with each property name.

Is the proposal here to instead create a list of property names based on 
the supported CSS property names (plus "offset", "easing", "composite", 
and maybe "computedOffset") and then do a [[Get]] on the object with 
each of those names?  That would better match up to how WebIDL handles 
dictionaries, for sure.  In fact, if we ignore the weird handling of 
"computedOffset", that would be expressible as a WebIDL dictionary.

The caveat is that in the common case of just a few properties on the 
object this would be a good bit slower, no?

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

That's actually pretty hard to do if you're trying to use WebIDL for 
some of them but not others, since the WebIDL processing model does 
WebIDL coercions for arguments (in order), then invokes the body of the 
function.  So anything that you want to do that can't be expressed in 
WebIDL really needs to be in the body, after all the arguments have had 
WebIDL processing.

Of course you can always spec the function as taking "any..." in the 
WebIDL and then do all the work by hand....

> (1) switch the input to element.animate (and the Animation constructor)
> from a big union to 'object'

That works.  This means that the timing argument will get coerced to 
(double or TimingInput) before the body of the function starts examining 
the "object" argument, but that seems ok to me.

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

See above.

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

I don't think so.  Argument processing happens before prose, so the 
second argument of animate() as currently specified is coerced before 
any of the prose happens.

-Boris

Received on Wednesday, 16 April 2014 06:42:55 UTC