- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 18 Jan 2013 13:57:48 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web animations minutes, 17 / 18 January 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.azLN80xgeWa/latest Present: Tab Atkins, Dmitry Baranovskiy, Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles Agenda: 1. Status update 2. Interface options: reworking time sources 3. Interface options: with or without Timing object 1. STATUS UPDATE ================ Doug: Polyfill - animation of rect(), shadow, visibility - all properties/types referenced by CSS Transitions supported - all other properties animated as non-numeric types (not interpolated) Shane: Polyfill - rest of length implemented - started implementing the rest of transforms Spec: - Spring timing research - play control proposal Brian: API research, play control review and proposal Steve: Latest TimeSource proposal, plus trial implementation in polyfill 2. INTERFACE OPTIONS: REWORKING TIME SOURCES ============================================ Brian's comments, research, and proposal: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Play_Control_Review http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Comparison Alternative proposal #2: * Have a separate PlayController object ** One per 'tree' * Animations / groups have controller member that returns a PlayControllerProxy--it tracks the PlayController associated with the timed item even when re-parented * Animations have a start() method. ''This'' is what you call when you first create an animation. ** Not sure about the semantics here when adding to a group etc., but for simple animations you create them, then call start * play() and pause() are on the controller * TimedItem.currentTime is read-only * PlayController.currentTime is writeable * Run-time playbackRate control (the version that does a compensatory seek) is on the controller * Setting TimedItem.playbackRate causes 're-layout' * Disadvantages: Different to HTML Discussed trade-offs and advantages of all three approaches. Looks like Brian still mostly doesn't like the Shane/Steve/Doug-preferred approach and Shane/Steve/Doug still mostly don't like the Brian-preferred approach. 3. INTERFACE OPTIONS: WITH OR WITHOUT Timing ============================================ (1) Discussed having vs. not having a timing item (2) Looked at the possibility of dropping one or both of activeDuration and iterationDuration, or at least making them read-only. (3) Did not reach consensus The two main options are as follows: Option 1: anim.startTime anim.currentTime anim.endTime anim.startDelay anim.iterationDuration anim.resetIterationDuration(); anim.activeDuration // read-only? anim.fillMode anim.playbackRate anim.(etc) Option 2: anim.startTime // READ ONLY - don't even provide and beef up AnimationController? anim.currentTime // READ ONLY - don't even provide and beef up AnimationController? anim.endTime // READ ONLY - don't even provide and beef up AnimationController? anim.timing.startDelay anim.timing.iterationDuration anim.timing.fillMode anim.timing.playbackRate anim.timing.(etc) anim.getActiveDuration() // getActiveDuration anim.getIterationDuration() // for groups, maybe even put on TimingGroup interface. Next meeting: Tues Jan 22, 16:00 PST / Wed 23 Jan 11:00 AEDST / Wed 23 Jan 9:00 JST @ https://etherpad.mozilla.org/pBOIanK3jm Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 18 January 2013 04:58:17 UTC