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

I discussed this with Boris on IRC, so here is my summary for the list:

(2014/04/16 15:42), Boris Zbarsky wrote:
> On 4/16/14 2:18 AM, Shane Stephens wrote:
 > ...
>> 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.

The differences here surround whether properties that are not marked as 
enumerable are visited or not, and whether properties on prototypes are 
visited.

If we defined this as using Object.keys we would only visit properties 
that are marked as enumerable on the object itself (not its prototypes).

That seems to be the most desirable behavior but I will follow up with 
public-script-coord after updating the spec to see if this is acceptable.


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

We discussed this approach as well but this is likely to be slow and to 
become increasingly slow as more properties become animatable 
(especially if we try to use this same approach for SVG which allows 
animating attributes). As a result, iterating over the input's 
properties seems preferable.


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

I'll spec this as doing the coercions for the timing argument first then 
the funky effect/keyframe handling.


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

I'll define a common definition for this handling and reference it from 
both these places.

I guess we should say that in the case of Animatable.animate, the 
"object" argument is processed (normalized) before constructing the 
Animation object (i.e. it isn't processed by the constructor of the 
Animation object) although I wonder if there's any observable difference.

Best regards,

Brian

Received on Wednesday, 16 April 2014 07:20:05 UTC