- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 16 Apr 2014 02:42:25 -0400
- To: Shane Stephens <shans@google.com>
- CC: "public-fx@w3.org" <public-fx@w3.org>
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