- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 10 Feb 2015 16:29:00 +1100
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 10 Feb 2015 Present: Doug, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.30455 Agenda: 1. Renaming and simplification 2. Reworking current / in play / relationship between nodes and players 3. Renaming to iterationCount, timingFunction, and fillMode 4. Promises again 5. Events 6. Additional input for keyframe effects? 7. Returning lists 8. Animation end behavior (Following is a summary of a very short ad-hoc meeting. Many topics raised, not many conclusions reached.) 1. RENAMING AND SIMPLIFICATION ============================== See: https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0042.html At a glance: * Remove AnimationEffect and roll into Animation * Rename Player -> Animation * Rename Animation -> AnimationEffect (= KeyframeEffect, GroupEffect, SequenceEffect) Concerns: Does this mean we can't share effects anymore? Specifically: sets of keyframes. Concern about the cost of parsing keyframes over and over again to clone. Perhaps we could make KeyframeEffect point to a KeyframeList object that could be shared? > Bring this up in FXTF tomorrow 2. REWORKING CURRENT / IN PLAY / RELATIONSHIP BETWEEN NODES AND PLAYERS ======================================================================= (Brian) I'm trying to straighten out the relationships in the model somewhat. I think the relationship between players and nodes (and likewise groups and children) should be, as far as possible, one way. That is nodes are basically dumb things that get an input time from something (a parent group, a player, potentially even script, it doesn't matter). The only time I think nodes need to know about their players/parents is when we do tree surgery and need to preserve the invariant that nodes aren't bound to multiple players/groups. Nodes themselves should never have to reach up to their parents. I looked at doing this in the spec and the only places the association between nodes and players is referenced is: * to define "inherited time" -- we should just rephrase this in terms of "input time" and make it sound more like push instead of pull * the "in play" definition which is used in the following ways: * to define non-normatively when fill modes apply, which could be fixed I'm pretty sure * to define "current" which we only use for getAnimationPlayers() which needs to be reworked anyway That last point is the sticking point: what should the behaviour for getAnimationPlayers() be? Do we actually want to return all animations? We probably want, for example, cancelled animations to be skipped. Could we just say all animations that aren't idle, and then say UAs will do their own filtering of results, beginning with animations that have finished that are not in effect? I'd actually prefer if it was more aggressive and never returned animations that have finished and are not in effect. On mobile, at least, it seems we'd like to drop those objects as soon as possible. It would be pretty neat to get rid of the "current" and "in play" states altogether if possible and just leave "in effect" (which is simply, is the active time null or not?) > To discuss later since we clearly weren't going to reach a resolution on this today in the time available. 3. RENAMING TO iterationCount, timingFunction, AND fillMode =========================================================== > Take to group 4. PROMISES AGAIN ================= Sub-topics: - Have a single promise or split them up? - Have start() which returns a promise? > Needs further discussion: e.g. if we add start shouldn't it parallel finish? What about resume()? unpause()? 5. EVENTS ========= Events are useful when re-using players because it saves you having to rebind to the (new) finished promise each time you restart the player. Brian still not sure if they are useful *enough*, but agrees they are useful. Shane has opposite opinion (of course) :-D > Take to the FXTF 6. ADDITIONAL INPUT FOR KEYFRAME EFFECTS? ========================================= Keyframes are always lists now. Proposal to add a dictionary input where properties are the keys, and values are always lists. Currently you can do: elem.animate({ left: '100px' }, 3000); To add a second frame you do: elem.animate([ { left: '100px' }, { left: '200px' } ], 3000); The proposal is to *also* allow: elem.animate({ left: [ '100px', '200px' ] }, 3000); The main difference to previous similar proposals is that you *can't* also specify positional offsets / composite modes etc. using this syntax. For that you need the list-of-frames syntax. > Shane to create a pull request. This should be gated on implementation experience (that should called out in the PR). 7. RETURNING LISTS ================== Re: getAnimationPlayers() which returns a sequence of AnimationPlayer objects we received feedback that this was "Java-ish". We want to check that this is the current best practice for returning lists. We also want to know with regards to setFrames()/getFrames(). > Brian to talk to heycam about what best practice is regarding returning lists. 8. ANIMATION END BEHAVIOR ========================= There seems to be confusion about the consequences of making a forwards-filling animation. Authors find it confusing that a forwards-filling animation clobbers any subsequence changes to the specified value of properties with animations. Not sure how to fix this. > Shane to raise this topic at FXTF Next meeting: TBD Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Tuesday, 10 February 2015 05:29:30 UTC