- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Wed, 02 Jul 2014 15:08:09 +0900
- To: Domenic Denicola <domenic@domenicdenicola.com>, "public-fx@w3.org" <public-fx@w3.org>
- CC: Cameron McCormack <cam@mcc.id.au>, Boris Zbarsky <bzbarsky@MIT.EDU>
Dear Domenic / public-fx, Having seen the recent discussion on public-script-coord about DOMRectReadOnly[1], a pattern I blindly copied into Web Animations last week,[2] I wonder if you can advise how we should arrange timing objects in Web Animations? Currently we have the following arrangement: interface AnimationTimingReadOnly { readonly attribute FillMode fill; readonly attribute (unrestricted double or DOMString) duration; ... }; interface AnimationTiming : AnimationTimingReadOnly { inherit attribute FillMode fill; inherit attribute (unrestricted double or DOMString) duration; ... }; interface ComputedAnimationTiming : AnimationTimingReadOnly { readonly attribute unrestricted double timeFraction; ... }; // Abstract interface inherited by Animation, AnimationGroup etc. interface AnimationNode { readonly attribute AnimationTiming timing; readonly attribute ComputedAnimationTiming computedTiming; ... }; // Passed to the ctor of Animation, AnimationGroup etc. dictionary AnimationTimingInput { FillMode fill = "auto"; (unrestricted double or DOMString) duration = "auto"; ... }; A few points of explanation: * None of these have constructors. I'll fix that (except AnimationNode which is an abstract interface inherited by Animation, AnimationGroup etc.) * Unlike DOMRectReadOnly, the members of AnimationTimingReadOnly are actually used as-is by ComputedAnimationTiming so it's slightly different in that regard. * What we are *trying* to do here is expose both the specified timing (which is input/output) and calculated timing (which is purely an output). Many of the fields are the same but sometimes the range of values differs. For example, the |duration| member of a returned ComputedAnimationTiming object will always be a double, not a string. Likewise, the |fill| value will never be "auto". * We've also added some attributes onto ComputedAnimationTiming that aren't on AnimationTiming(ReadOnly) like timeFraction etc. Perhaps they don't belong there since they're more about *current* state rather than the result of resolving timing parameters but maybe it's ok? Questions: * What do you think of this hierarchy? Is there a better way of keeping AnimationTiming and ComputedAnimationTiming in sync without introducing AnimationTimingReadOnly? * Or should computedTiming just return a snapshot object with different object identity every time it changes? Perhaps a method that returns a dictionary object? * I guess AnimationNode.timing should not be readonly? I think making it [Replaceable] might be problematic from a performance point of view but if we define setting as doing a member-wise copy is that idiomatic? For example, is this better? [Constructor (AnimationTimingInput timing)] interface AnimationTiming { attribute FillMode fill; attribute (unrestricted double or DOMString) duration; ... }; dictionary AnimationTimingInput { FillMode fill = "auto"; (unrestricted double or DOMString) duration = "auto"; ... }; dictionary ComputedAnimationTiming : AnimationTimingInput { unrestricted double timeFraction; ... }; interface AnimationNode { attribute AnimationTiming timing; ComputedAnimationTiming getComputedTiming(); ... }; We'll probably have similar questions with regards to AnimationPlayers and AnimationNodes. We talked about making AnimationNodes generated from CSS be read-only so you'd have to clone it if you wanted to modify it rather than ending up in a situation where the object is partly live due to being partially overridden by script. That's a separate discussion but your suggestions to the above will probably help guide that. Best regards, Brian [1] http://lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0267.html [2] http://dev.w3.org/fxtf/web-animations/#idl-def-AnimationTimingReadOnly
Received on Wednesday, 2 July 2014 06:08:36 UTC