Web Animations minutes, 31 July / 1 Aug 2012

Web Animations minutes, 31 July / 1 Aug 2012

Etherpad: https://etherpad.mozilla.org/cCyjOIuU4q
Present: Dmitry Baranovskiy, Alex Danilo, Tab Atkins, Brian Birtles

Agenda:
1. Making templates optional?
2. Intervals
3. Representing effects vs animations
4. Liveness

1. MAKING TEMPLATES OPTIONAL

It seems like for most use cases templates are unnecessary. i.e., when 
you're using the API from script, you very often just want to animate a 
single element once.

Is it out of the question to extent Element.protoype?

i.e. Element.animate(....) like you can do in Raphael??

 > Ask public-webapps, since Element extensions may clobber author stuff 
in form event handlers.  This usually requires an analysis of existing 
content/experimental implementation to see if things break.

If we do that, it means you less often need to use the template classes 
directly and we can probably rename as follows:

s/Anim/AnimProto/
s/AnimInstance/Anim/

which makes more sense to me.

Alternative: make a global Anim object or function and pass the target 
element and params

   Anim.animate(elem, params)

Global function:

   Animate(elem, params)

   Advantage of this is that it extends very easily toward animating 
other things. For example, if you want a requestAnimationFrame() variant 
that tied into animation timing (so that you get timing functions, 
reversing, etc.), you could pass a callback function as the first 
argument to Anim.animate().

 > The global function seems to be the preferred approach.

2. INTERVALS

Maybe we don't need intervals after all. The main reason we needed them 
was for when you have an animation that:

* is additive
* has a forwards fill
* runs twice or more

When it runs the second time you don't want it to add onto the previous 
fill value.

--- Some background information ---

Additive animation:

additive = sum | replace
<animate attributeName="width" from="100" to="200" freeze="fill"/>
<animate attributeName="width" from="100" to="200" freeze="fill" 
additive="sum"/>
Final result: 400

Cumulative animation:

accumulate = sum | none?
Additive animation:
<animate attributeName="width" to="100" repeatCount="2" accumulate="sum"/>
Final result: 200

Additive animation and multiple intervals:

<animate begin="1s; 5s" dur="1s" attributeName="width" from="100" 
to="200" freeze="fill" additive="sum"/>
Final result: 200

--- End background information ---

SVG syntax aside, there's a fundamental requirement to be able to run 
the same animation twice on a target so that it:

A) overrides the result of the previous run, BUT
B) adds to any underlying animations

I tried introducing intervals to the API to support this but it 
introduced all sorts of problems and makes the API really complicated.

I think we have a few options here:

a) Add intervals to the API and just deal with the complexity
b) Add intervals to the SVG specific subclass of AnimInstance and 
AnimGroupInstance since that's where you're most likely to use it
c) Add a further "additive" state, i.e.
   additive = (i) don't add ever, (ii) add to underlying values but 
ignore the component introduced by animations generated by the same 
template, (iii) add to the underlying value no matter what
d) Make additive behavior do (ii)... perhaps if (iii) is really useful 
then we could add that as a further state for accumulate behavior (i.e. 
accumulate from previous iterations vs accumulate from previous runs)
I personally prefer (d) with the extension to accumulate behaviour

Both (c) and (d) effectively use multiple AnimInstance objects to 
represent the different intervals.

Another way of comparing (c) and (d) is as follows
c)
additive = replace | sum-unique | sum-all
accumulate = none | sum
d)
additive = replace | sum
accumulate = none | sum-repeat | sum-all
(Alternatively we could leave accumulate as-is and add a sum-all value 
later if it proves useful)

 > General preference for (c) or (d), i.e. we won't introduce intervals 
to the API yet. As for deciding between (c) and (d), (d) seems better 
but we'd like Shane's feedback.

3. REPRESENTING EFFECTS VS ANIMATIONS

Just a separate timeline. What to name them?

Document.animTimeline => contentTimeline?
Document.effectTimeline

 > contentTimeline seems better than animTimeline

How about the global animation function?

Animate(elem, params) ?
Effect(elem, params) ?

Animate.effect(elem.param) ?
Animate.timeline.content
Animate.timeline.effect

Animate(elem, params)
Animate.effect(elem, params) <-- this is more common?

Anim.content(…)
Anim.effect(…)

 > For now we'll go with
Animate(elem, params)
Animate.effect(elem, params)

What about animations in glyphs, backgrounds, etc. where do they live?

 > Effects timeline. They can still be individually seeked if necessary, 
just the timeline can't be seeked.

When should the effects timeline start?

 > Starts immediately. i.e. only the contentTimeline is initially paused.

4. LIVENESS

See last meeting's notes: https://etherpad.mozilla.org/uopQHnzOoX, point 4

Liveness is hard.

One possibility we considered is re-using Javascript's prototype chain 
to achieve liveness. This would allow merging AnimInstance and Anim into 
one which is very attractive.

How would it look like?

Anim,
instance = new Anim(element, …);
instance.timing.duration = 3;
var instance2 = instance.animate(elem);
? instance2.timing_duration // 3
? instance2.__proto__ === instance

instance.timing_duration = 5
? instance2.timing_duration // 5

instance2.timing_duration = 1;
? instance.timing_duration // 5
? instance2.timing_duration // 1

 > Some concerns about the complexity of this, whether it can be 
expressed in WebIDL, how it works for properties of properties etc. 
Needs more thought.

 > For now we can probably just drop the existing liveness scheme. For 
the first version we can probably live without liveness (hah!): SVG and 
CSS do their own bookkeeping. Still worth looking into the prototype 
approach however.

 > Also need to think about whether we can merge Anim/AnimInstance anyway.

Next meeting: 7 Aug 18:20 PDT / 8 Aug 11:20 AEST / 8 Aug 10:20 JST @ 
https://etherpad.mozilla.org/bfJdTefySR

Received on Wednesday, 1 August 2012 03:25:10 UTC