Server Notice:

hide

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

 
Web animations minutes, 21 / 22 March 2013
 
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
6. Merging
 
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.
 
BUT
 
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!
 
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)
 
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')}
 
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.duration = 3;
anim.setSpecified(timing);
 
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
 
5. SHRINKING THE API SURFACE AREA
================================
 
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.