Server Notice:


Public Pad Latest text of pad pHPfOqZA75 Saved March 22, 2013

Web animations minutes, 21 / 22 March 2013
Present: Doug, Shane, Steve, Brian
1. Status update
2. Clarifying the mapping re: to-animation
3. getCurrentPlayers/getCurrentAnimations
4. The specified timing
5. Shrinking the API surface area
6. Merging
- Reworking animation section
- improving automated testing
- Media integration
In CSS you can do
@keyframes foo {
    from {
i.e. with a 0 value keyframe and nothing else.
to be clear
@keyframes foo {
    to {
<animation to="..."/>
In fact the CSS version is much easier to implement because it snapshots the missing state.
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.
Brian's proposal: when 0 or 1 keyframes are missing, use the live underlying value.
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!
  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)
Hey wow 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')}
Spec check (hasn't been updated yet).
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.duration = 3;
anim.getSpecified().duration // reading is still easy
One advantage of this is that it does tend to warn of the potential of significant effects. It also buys us a bit of wiggle room if we want to complexify timing later. It also removes the need for that pesky additional Timing interface.
> Try adding this for now and add an issue highlighting other possibilities (specifically adding a Timing interface, and putting the members directly on TimedItem)
// What happens here?
So anim.setSpecified({ duration: 3 })
You'd clobber all the existing values with the dictionary 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
One radical proposal: in v1 don't expose TimingFunction data structure, just the string representations.
> Sounds good
Action: Shane to consider whether this is possible for keyframe objects too.