- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 14 Dec 2012 14:09:36 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web animations minutes, 13 / 14 December 2012 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.JmTgOwIT-so/latest Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles Agenda: 1. Status update 2. CSS WG resolutions review 3. PathAnimationEffect proposal 4. Events 1. STATUS UPDATE ================ Brian: * Rename AnimationFunction -> AnimationEffect * Make Animation.effect nullable * GroupedAnimationEffect work * Fix iterationStart behaviour * Bug fixes (thanks Steve!) 2. CSS WG RESOLUTIONS REVIEW ============================= http://lists.w3.org/Archives/Public/www-style/2012Dec/0188.html - RESOLVED: Transitions defines the timing functions, Animations has normative dependency on Transitions for them. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14784 - RESOLVED: Animations only "run" (fire start events, etc) if they have at least one valid keyframe. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15251 Brian: I'd like to revisit this decision for the following reasons: * There are valid use cases for an 'empty' animation that fires events such as to simply to get the events and do appropriate actions (particularly when running off a global clock). * If you later allow sequencing and such an animation is part of the sequence, you'd expect it to take time--why wouldn't it fire events too? * It's useful to think of animations in two parts timing+animation. Events relate to timing. They should still fire regardless of whether there is an animation or not. I (Brian) recently made Web Animations support having a 'null' animation function for these reasons. If CSS differs in this area it will confuse authors and complicate the mapping (since at the point where you remove a keyframe you'll also have to somehow disable or remove the corresponding Animation object(s)). On further thought, this doesn't effect us too much since the CSS bindings would simply not generate an Animation when there are no keyframes. > Brian might get back to CSS WG about this - RESOLVED: When an element changes from display:none to display: non-none, animations start immediately. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14785 Brian: not sure this has much effect on us? An issue for the CSS mapping? - RESOLVED: An initially-paused animation is still started (fires start events, etc.) https://www.w3.org/Bugs/Public/show_bug.cgi?id=14774 Brian: Not sure if we do this. I thought we resolved to do this but it doesn't look like the algorithms actually do this yet? i.e. if you pause before the start time it doesn't start? > Brian to look into this - RESOLVED: Animations can be paused during their delay phase, which freezes the remaining delay to be applied after it unpauses. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14774 Brian: Pretty sure we do this. - RESOLVED: animation-play-state is not in the shorthand on purpose https://www.w3.org/Bugs/Public/show_bug.cgi?id=14787 Brian: doesn't effect us - RESOLVED: animation-play-state has the same list behavior as the other animation properties, matching the length of animation-name. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14786 Brian: doesn't effect us - RESOLVED: Look into "adjacent keyframes" for level 4, but not for the current level. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20092 Brian: We already support this 3. PathAnimationEffect PROPOSAL =============================== > Currently tracking SVG fairly closely at this stage. Still need to think about how to incorporate paced timing into the model and ordering of path animations vs regular transform animations from a compatibility point of view. 4. EVENTS ========= Briefly discussed how we can unify CSS and SVG events. Possibility of delaying to v2. One common use is: elem.animate({ opacity: '0%' }, 1).onend = function() { elem.parentNode.removeChild(elem); }; Disagreement about the criticality of events to the API. > Brian to spec it out and mark it as 'at risk'. We'll seek wider feedback later about how critical this is. Next meeting: Mon Dec 17, 17:30 PST / Tues 18 Dec 12:30 AEDST / Tues 18 Dec 10:30 JST @ https://etherpad.mozilla.org/JNHdgLfAYm Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 14 December 2012 05:10:11 UTC