- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 25 Jul 2014 09:04:41 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 24 July 2014 Present: Doug, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.23508 Agenda: 1. Orphaned players 2. Promises again 3. Shipping more of phase 1 4. Bikeshed 5. Do you need a timeline? 1. ORPHANED PLAYERS =================== (Shane) We initially decided that we needed to orphan players [that is, not return forwards-filling players from getAnimationPlayers] because defaulting to forwards fill meant an author could gradually accumulate hundreds of players that couldn't be removed, without even realizing they were doing so. The default fill is 'none' now, which means that most players will stop contributing once they reach the end of their active region. The original reason we had for some kind of orphaning mechanism doesn't seem to exist any more. Should we just change the definition of getAnimationPlayers to return filling players too? Doug: I'm a bit worried about the use case of playing and forgetting about forward-filling animations. It makes that a little bit more awkward. People will need to know that they need to clean up animations, or they'll leak memory. Discussion points: * Having getAnimationPlayers always return all "in effect" animations is attractive in its simplicity, it's easy to understand * Authors understand that adding lots of DOM elements etc. take up resources but animations are somehow different. Authors may assume that when animations finish and are masked by other animations that they no longer consume resources. * Groups have a default fill mode of "both" so currently if you were trigger a group animation over and over again we'd hit the same issue. Perhaps we could redefine "is current" so a group that fills forwards isn't current if none of its children are filling? * What about another kind of fill mode that fills until something else affects all the properties affected by that animation? * Why don't we just allow implementations to drop such animations arbitrarily when we reach some implementation-defined limit? Shane: I think this is a lesser issue than what the other suggested approaches have needed to introduce: either a complexification of the entire API, or behaviour dependent on whether a JS handle is maintained or not. > Make getAnimationPlayers() return all "in effect" animation players and add an issue about the memory pressure this may produce. 2. PROMISES AGAIN ================= (Shane) We should synchronize with whatever img.onload are doing. > Shane to follow up * Some discussion of whether getCurrentTiming should actually be a dictionary attribute. This isn't allowed by WebIDL yet but it seems likely to be added in the future. Shane to follow-up on the Chrome side to see if this is feasible there. 3. SHIPPING MORE OF PHASE 1 =========================== We're thinking of targetting m39 (this goes to stable mid-November) for shipping more of the player API, but wanted to discuss this in the spec meeting with plenty of lead time :) Brian: Obviously need to make sure the spec has stabilized in this area first, but sounds good in principle. > We also had a discussion of getCurrentPlayers and CSS integration. Brian provided a link to some early tests: http://dxr.mozilla.org/mozilla-central/source/dom/animation/test/css-integration. It seems like there's still a lot of CSS Animation specification instability which is making it hard to decide what some of this behaviour should be. 4. BIKESHED =========== Coming along nicely. 5. DO YOU NEED A TIMELINE? ========================= Is it valid to have an AnimationPlayer without a timeline? And if so, can you just set the currentTime and so, effectively create a script-driven timeline? Next meeting, Thurs 14 Aug 2014 07:00 UTC Local time: http://arewemeetingyet.com/UTC/2014-08-14/07:00/Web%20Animations Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 25 July 2014 00:04:47 UTC