Re: [csswg-drafts] [web-animations-2] AnimationWorklet integration - using GroupEffect and allowing control of localTime

> We already have the getTiming().localTime member. I wonder how this should interact. Should we set it through updateTiming() instead?
> 
> So I take it that the suggesting is that we add the localTime to OptionalEffectTiming and EffectTiming dictionary. So authors can do effect.updateTiming({localTime: 123.4});
> 
> This can work for animation worklet usecases. If making localTime writable is acceptable in general then I am in favor of having a consistent API here.

I think it would be useful to be able to set `localTime` on `AnimationEffect`s not bound to an `Animation` in general. This would let you have a completely free-standing way of driving an animation.

For an `AnimationEffect` that is associated with an `Animation`, I suspect we would just throw if you tried to set the `localTime`.

The question still remains whether you should set it by doing `effect.localTime = 1000` or `effect.updateTiming({ localTime: 1000 })`, however.

Having thought about this a little further I start to lean towards `effect.localTime = 1000` or something other than `updateTiming()`.

My original comment was wrong when I suggested we already have `getTiming().localTime`. It's actually `getComputedTiming().localTime`.

Making it possible to set `localTime` through `updateTiming()` would also suggest it's no longer part of computed timing, and should be returned from `getTiming()`. That seems awkward.

There's also the concern that the following would begin to throw in some circumstances when it previously didn't:

```js
effectB.updateTiming(effectA.getComputedTiming());
```

Authors should really be using `getTiming()` in that case but they may well end up doing the above.

In light of that, having a means to setting `localTime` outside of `updateTiming()` seems like the way to go.

Regarding the `localTime` attribute approach, the overlap between `effect.getComputedTiming().localTime` and `effect.localTime` seems unfortunate. I'm not sure how to fix that other than adding something like `effect.setLocalTime(1000)` however.

> Turns out webidl sequence types are not allowed for attributes. So I suggest using a getter function for now and we can add an update function in the future. e.g.,
> 
> interface WorkletGroupEffect {
>   sequence<AnimationEffect> getChildren();
> }

Right. Web Animations Level 2 introduces the [`AnimationNodeList`](https://drafts.csswg.org/web-animations-2/#animationnodelist) for this reason. That spec is out of date, but if we were to introduce that approach again we'd call it `AnimationEffectList` and get rid of the `ReadOnly` distinction.

I'm pretty sure you can use a frozen array as an attribute but I've no idea if that's a good idea or not.

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2071#issuecomment-410562399 using your GitHub account

Received on Monday, 6 August 2018 01:03:06 UTC