[web-anim] Web animations minutes, 21 / 22 March 2013

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