- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 22 Mar 2013 14:31:39 +0900
- To: "public-fx >> \"public-fx@w3.org\"" <public-fx@w3.org>
Web animations minutes, 21 / 22 March 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.sK23RslD$VL/latest Present: Doug, Shane, Steve, Brian Agenda: 1. Status update 2. Clarifying the mapping re: to-animation 3. getCurrentPlayers/getCurrentAnimations 4. The specified timing 5. Shrinking the API surface area 1. STATUS UPDATE ================ Brian: - Reworking animation section Shane: - improving automated testing Steve - Media integration 2. CLARIFYING THE MAPPING RE: TO-ANIMATION ========================================== In CSS you can do @keyframes foo { from { ... } } i.e. with a 0 value keyframe and nothing else. However, note that @keyframes foo { to { ... } } is not that same as: <animation to="..."/> Since CSS snapshots the underlying values. This makes the CSS version much easier to implement. Looking at web animations: new Animation(foo, {left: "100px"}) does an SVG to-animation var x = document.getComputedStyle(foo).left; new Animation(foo, {left: [x, "100px"]}) does a CSS to-animation var x = document.getComputedStyle(foo).left; new Animation(foo, {left: ["100px", x]}) does a CSS from animation ---- Brian's concern: automatically switching to MERGE behaviour in the constructor when only one value is specified is clumsy and surprising. (Background: this is behaviour we've currently discussed where 'new Animation(foo, {left: "100px"})' automatically chooses a 'merge' composition operator whilst 'new Animation(foo, {left: ["100px"]})' chooses a 'replace' composition operator.) Brian's proposal: when 0 or 1 keyframes are missing, use the live underlying value (similar to what CSS does except that the underlying values are live). So provide a value at 1 of 200px, with an underlying value of 100px: 'replace' will linearly interpolate from 100px to 200px 'add' will linearly interpolate from 200px to 300px 'merge' will quadratically interpolate from 100px to 200px ---- Shane's concern: doing something special to the 0 and 1 values that isn't available to other keyframes is inconsistent and surprising. Shane: what if we added the compositing operator to the keyframes themselves? Then we wouldn't need merge at all! e.g. new Animation(foo, {left: [{offset: 0}, {offset: 1, '100px'}]; new Animation(foo, {left: [{offset: 0}, {offset: 1, '+100px'}]; or maybe: new Animation(foo, {left: [{offset: 0, add: '0px'}, {offset: 1, set: '200px'}]}) Here's what happens to generate a 'to' animation: new Animation(foo, { left: '100px' }) // specified by programmer new Animation(foo, { left: ['100px'] }) // popped into list (by ctor) new Animation(foo, { left: [{offset: 1, set: '100px'}] }) // expanded to include offset value (by ctor) new Animation(foo, { left: [{offset: 0, add: '0px'}, {offset: 1, set: '100px'}] }) // zero offset keyframe constructed (happens during animation value generation) Now you could even do: new Animation(foo, { left: [{offset: 0, set: '100px'}, {offset: 0.5, add: '0px'}, {offset: 1, set: '100px'}] }); Use cases (these are the things that should be simple) (1) to animation (SVG) (2) "normal" animation (SVG & CSS) (3) Additive animation (SVG incl. by-animation) (4) snapshotting initial / final state (CSS) ACTION: Shane to flesh this out and make sure it will work with all animation types (due date: Wed 3rd Apr) (another syntax proposal) {offset: 0, value: '100px'}, {offset: 1, value: add('100px')} 3. getCurrentPlayers / getCurrentAnimations =========================================== Spec check (hasn't been updated yet). 4. THE SPECIFIED TIMING ======================= Results of data gathering... Cameron says dictionary objects are always pass-by-value and we probably just need to introduce a separate Timing interface. > Let's just add the Timing interface for now along with an issue indicating that we might reconsider it What about sharing? > For now we make the 'specified' attribute readonly (i.e. you can't assign a Timing object to it--after all you can't construct a Timing object). If we find a sensible way to share stuff in the future we can remove the restriction then. Brief discussion on using getters and setters: var timing = anim.getSpecified(); timing.iterationDuration = 3; anim.setSpecified(timing); Note that although this seems awkward, one advantage of this is that it does tend to warn of the potential of significant effects (i.e. the animation might jump suddenly). It also buys us a bit of wiggle room if we want to support more complex timing structures later (various ideas about linked/templated timing structures have been floated from time to time). It also removes the need for that pesky additional Timing interface. Note that reading values is still reasonably straightforward: anim.getSpecified().iterationDuration > Try adding this for now and add an issue highlighting other possibilities (specifically adding a Timing interface, and putting the members directly on TimedItem) One issue though. What happens here: So anim.setSpecified({ iterationDuration: 3 }) You'd clobber all the existing values with the dictionary's default values. That's a bit surprising. One alternative is to make the default values for the dictionary have some special "auto" value that are interpreted so they don't clobber. > Put an issue in the spec about this 5. SHRINKING THE API SURFACE AREA ================================ One radical proposal: in v1 don't expose TimingFunction data structure, just the string representations. > Sounds good It would be nice if there were other parts of the interface where this was possible. Action: Shane to consider whether this is possible for keyframe objects too. Next meeting: Thurs Apr 4 16:00 PST / Fri 5 Apr 10:00 AEDST / Fri 5 Apr 08:00 JST @ https://etherpad.mozilla.org/i6bC4S4gzA Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 22 March 2013 05:32:10 UTC