- From: Antoine Quint via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Jan 2018 08:55:54 +0000
- To: public-css-archive@w3.org
Thanks for putting this all together @birtles. I'm in support of dropping the `ReadOnly` interfaces. I think the only real disadvantage here is the loss of a simple way to update timing properties individually, which I think is a real use case. One in particular to me is developer tools, such as the WebKit Web Inspector, where we'll definitely want to offer a way, graphical or more code-oriented, to toy with individual timing properties. But I think we can have a good answer to that if we make members of `AnimationEffectTimingProperties` optional and treating unspecified values as a way to **not** overwrite the current values. That means that we should be able to do this: ```javascript // Current API anim.effect.timing.duration *= 2; // Proposed API anim.effect.updateTiming({ duration: anim.effect.getTiming().computedDuration * 2 }); ``` In practice it's pretty similar to what you were proposing but somehow feels lighter-weight to me. And in cases where you want to set the new duration to a value that is not tied to a previous value, then it starts being a lot nicer: ```javascript anim.effect.updateTiming({ duration: 2000 }); ``` As for the name, if we allow for `AnimationEffectTimingProperties` values to be optional, then I think `updateTiming()` is a superior name since we're not setting all timing properties, but just some based on the keys specified in the provided dictionary. Otherwise, if we provide a complete snapshot coming out of `getTiming()`, I think `setTiming()` is a better name, since you're really setting all properties. -- GitHub Notification of comment by graouts Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2065#issuecomment-357893474 using your GitHub account
Received on Tuesday, 16 January 2018 08:55:56 UTC