[web-anim] Web animations minutes, 10 / 11 December 2012

Web animations minutes, 10 / 11 December 2012

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.AY7jk02mILP/latest
Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles


1. Status update
2. Time sources
3. Groups and time windows
4. Small fry


- Finished changes to KeyframeAnimation interfaces

- Still working on adding TimeSources to polyfill, hung up on numerous 
bugs in existing logic.

- Implemented color handling in polyfill, thinking about Timing

- Implemented PathAnimationFunction in polyfill using 


Summarising where we got to last time:
- We think separating time sources from parent ownership may be a useful 
separation of concerns for some use cases
   - and conflating the two may be counter-intuitive
- Brian is concerned about overcomplicating v1

One possibility for v1:
- TimedItem's have a timeSource property - points to a TimeSource
- When a TimedItem is a child of a par/seq group, the timeSource 
property will point to that par/seq group
- If in a future version we want to allow children to have separate 
parents and time source we add a parentGroup property then
- Can you modify TimedItem.timeSource to re-parent? I *think* the answer 
might be no

 > No agreement here

 > Shane to write up something about Timeline -> TimeSource transformations

(Continuing discussion from last time)

- How do we handle video?
e.g. You have a seq container with a video, followed by some credits / music
If the *user* presses pause / seeks the video (using the browser 
controls) you probably don't want the windowing behaviour.
Need to think a bit more about how buffering works too (probably maps to 
a kind of pausing). Just flagging these as issues for now.

- I think taking the time window approach depends on us being able to 
work out an API for representing it that feels simple.


a. We floated the idea of implementation on webkit-dev and received some 
push-back. Notably, some thought that name shortening was "unwebby". 
Should we revert Anim → Animation, Func → Function? Or do we have 
"webby" examples of name shortening we can point to?

Brian: I sympathise with this criticism.
   Proposed longification:
   Anim → Animation
         To address the concern about this being too long to type I 
wonder if we can extend Element with an animate method? (a la Raphaël)
   AnimGroup → AnimationGroup
      This happens to match the naming in Core Animation
   ParAnimGroup → ParGroup?
   SeqAnimGroup → SeqGroup?
      (These 'par' and 'seq' abbreviations already have established 
usage due to SMIL and I expect an element syntax would probably use 
these names. ParallelGroup is particularly error-prone to type 
especially for non-native English speakers.)
   TimingFunc → TimingFunction (you don't type this as often except when 
you access anim.timingFunction)
   AnimFunc → AnimationFunction (see below)

2012-11-29[Brian]: Made the above changes but I still want to get 
feedback about extending Element.

Basically, it would let you do this:

   elem.animate({ opacity: '0%' }, 1).onend =
      function() { elem.parentNode.removeChild(elem); };

 > Agreed, we'll put it in for now

The other remaining renaming is that I'm not really happy with 
KeyframesAnimationFunction. How are these:

     AnimationFunction -> AnimationAction
     KeyframeAnimationFunction -> KeyframeAction
     GroupAnimationFunction -> GroupAction
     PathAnimationFunction -> PathAction
     CustomAnimationFunction -> CustomAction
     AnimationFunction -> AnimationEffect
     KeyframeAnimationFunction -> KeyframeEffect
     GroupAnimationFunction -> GroupEffect
     PathAnimationFunction -> PathEffect
     CustomAnimationFunction -> CustomEffect
     AnimationFunction -> AnimationEffect
     KeyframeAnimationFunction -> KeyframeAnimationEffect
     GroupAnimationFunction -> GroupAnimationEffect
     PathAnimationFunction -> PathAnimationEffect
     CustomAnimationFunction -> CustomAnimationEffect

I'm leaning towards (c).

 > Agreed to go with (c) for now.

Shane: One major piece of feedback in general is that the spec looks 
huge. It is, but the implementation size is small. The polyfill will 
help here, and a primer might too. One of our engineers is interested in 
maybe writing a primer. Good idea?

 > If one of us is bored we'll do it

b. 6.13.2. point 3 really needs some explanatory text.

 > Steve to email Brian/Shane with corrected code for point three of 
calculating the unscaled iteration time

c. does iterationStart = 0.5 & iterationCount = 2 cause (iteration + 
timeFraction) to start at 0.5 and sweep to 2.5? If so, why is 
iterationStart capped to iterationCount?

Shane: I think we all accept that iterationCount should actually match 
the count of iterations, so I think it's OK to remove the requirement 
that iterationStart is capped to iterationCount. Should we remove the 
requirement that iterationStart > 0 too?

Brian: Good question. I'm not sure. I've a feeling we generally try not 
to have negative times but I'm not quite sure why. How would an 
accumulate animation work in negative time?

 > Yes, it should sweep from 0.5 to 2.5. Yes we should remove the cap of 
iterationCount on iterationStart. No we shouldn't let it go below 0 
(accumulate acts weirdly).

Is there a use case for iterationStart > 1?

 > For now let iterationStart be limited to >= 0. [0, ∞)

d. what should happen if timing parameters are changed after an 
animation is finished?
case A
var a = Anim(..., 2)
// @ 3 seconds
a.timing.duration = 4

case B
var a = Anim(..., 2)
// @ 5 seconds
a.timing.duration = 4

case C
var a = Anim(..., 2)
// @ 3 seconds
a.timing.iterationCount = 2


Brian: We need to talk about this. It relates to having a stateless 
timing model.

 > We agree that stuff should come "back into scope" if the duration or 
iterationCount is changed.

e. How about a root timeline with global time that underlies the 
document timelines? This would enable global-clock-synchronized 
animations (e.g. clock-tick animations and the like) at very little 
additional complexity cost.

Brian: Sounds attractive for syncing animations with event timestamps.

 > Defer until we discuss some of the above stuff in [1-3]

f. Why do we have startDelay but not between-iteration-delay or 
endDelay? Triggers partly address this.

Brian: I think we discussed this and decided to defer it?

 > Yes. Defer until after v1.

g. Should we expose reversing state? Should it be reversed / 

Brian: I think this comes up somewhere else. I'd like to not have a 
special reversing flag since otherwise there are three places to check 
to determine if an animation is going backwards or not--playbackRate, 
direction, and reversed.

 > Agreed we want to implement reversing in terms of playbackRate (and 
fillMode) so we don't have three independent properties that control 
 > Defer adding reversed property (getter to query direction) until we 
see some use cases

h. Steve: Need to confirm desired behaviour for default animation start 
times within parent groups.

Brian going off track talking about autoplay behaviour...
  - Need to consider if we can align better with HTMLMediaElement's 
autoplay behaviour
  - May be surprising that simply creating an Animation object kick 
starts it. A number of people have expressed surprise at this.
    - Seems to be agreement that 'new Animation' kick-starts an 
animation. Not sure exactly what state a new Animation should be in, but 
it probably shouldn't start until you call play(). If you want to create 
and start a simple animation then the proposed Element.animate method 
will be the way to go there.

The issue here is when you have an Animation that DOESN'T have a start 
time and you add it to a par group
  - currently it uses the current iteration time of the parent as the 
start time
  - that's counter-intuitive when you're repeating since on the next 
iteration the animation starts part-way through
  - it also might be counter-intuitive when reversing since you won't 
see the animation until the prev iteration (although this may be 

 > Steve to think about alternative behaviour

One note to bear in mind is that the current behaviour was decided at a 
point where we expected Animations by default would be added to a 
document-level par group and this may no longer be the case.

Next meeting: TBD @ https://etherpad.mozilla.org/Gwv1poQiPW

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Tuesday, 11 December 2012 03:50:46 UTC