- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 06 Sep 2013 14:41:26 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 5 / 6 Sep 2013 Present: Dean, Shane, Brian Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.QrHFsG$54jB/latest Agenda: 1. Status updates 2. Feedback from Dean 3. Allow the children of groups with infinite duration to play as expected 4. Should time be frozen in JavaScript callbacks? 5. Fill control 6. Naming of <par> and <seq> (ParGroup and SeqGroup) 1. STATUS UPDATES ================= Brian: - Added timing function chains to spec based on Steve's draft - Started writing up SVG integration: http://dev.w3.org/fxtf/web-animations/animation-elements.html 2. FEEDBACK FROM DEAN ===================== Still concerned about API surface area. How can we expose this incrementally? Possible staged release: 1. Element.animate -- but what does it return? An opaque Animation? 2. Element.getCurrentAnimations etc. 3. Timing groups For a staged release, what should element.animate return? An opaque type might be quite frustrating to content. They will have to test if the object has particular properties available, etc. Names in the global namespace: We need to be careful when exposing so many new names into the global namespace. e.g. Player SeqGroup (especially if we rename it "Sequence") Timing Tension between safe names and long names. What do do? > Brian to mail the list 3. ALLOW THE CHILDREN OF GROUPS WITH INFINITE DURATION TO PLAY AS EXPECTED ========================================================================== https://github.com/web-animations/web-animations-js/pull/466 The issue comes up in the following case: document.timeline.play(new ParGroup([ new Animation(foo, bar, {iterations: Infinity, duration: 2}), new Animation(foo, bar, {iterations: Infinity, duration: 3}), ])); The duration of the ParGroup is Infinity, because it's calculated from the children. You'd expect these animations to play forever, but currently they never start (because time never advances into the child over an infinite duration in the parent i.e. the timing function will never return a non-zero value) The proposal is to ignore the timing function in these cases, and simply set the current time of an infinite-length element to be the scaled current time of the parent. We think this actually is consistent behavior, not a special case. > Brian to fix in spec 4. SHOULD TIME BE FROZEN IN JAVASCRIPT CALLBACKS? ================================================= https://github.com/web-animations/web-animations-js/issues/467 http://dev.w3.org/fxtf/web-animations/web-animations.html#script-execution-and-live-updates-to-the-model - the 4th bullet point. Seems to be pretty clear from this that time needs to be frozen. > Steve, can you please follow-up the issue in github or here and point out which part is unclear? 5. FILL CONTROL =============== Brian: I think it's really useful to have an animation fill to the end of a parent (ancestor?) container but no further. Shane: +1. Isn't this just fill:forwards in the child and fill:none in the parent? Brian: Actually the problem is that you want some things to terminate at the parent (but not before), and some things not to. Shane: You can do this but it's not pleasant: <par fill='forwards'> // parent group <par fill='none'> // group for things that stop at the parent ... </par> <par fill='forwards'> // group for things that don't stop ... </par> </par> Use cases: - Cartoon animation -- you set up scenes and things that start during the scene fill until the end of the scene. e.g. you slide something onto the stage, manipulate it etc. then at the end of the scene it should just disappear off stage again - Reverse transition -- you have a complex animation that performs some change and fills the result. Then you perform a reverse using a to-animation... no, actually, I forget where this was going > Will come back to this later once we have more concrete use cases 6. NAMING OF <par> AND <seq> (ParGroup AND SeqGroup) ==================================================== (Dean) We're following SMIL naming here, but I don't think there is a need to do so. "Sequence" is a very clear and universally understood name. (Not sure what the equivalent of <par> is... "Group" seems ok to me although it is already being used). > Brian to include this in his mail Next meeting: Fri 20 Sep 01:00 UTC @ https://etherpad.mozilla.org/UgIGNnOjfG Local time: http://arewemeetingyet.com/Sydney/2013-09-20/11:00/Web%20Animations (Note that we will probably meet every second week from here onwards since the number of issues seems to have dropped) Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 6 September 2013 05:41:55 UTC