[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

Agenda:

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

1. STATUS UPDATE
================

Brian:
- Finished changes to KeyframeAnimation interfaces

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

Shane:
- Implemented color handling in polyfill, thinking about Timing

Doug:
- Implemented PathAnimationFunction in polyfill using 
SVGPathElement#getPointAtLength

2. TIME SOURCES
===============
(Brian)

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

3. GROUPS AND TIME WINDOWS
===========================
(Continuing discussion from last time)

Brian:
- 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.

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

4. SMALL FRY
============
(Shane)

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:

(a)
     AnimationFunction -> AnimationAction
     KeyframeAnimationFunction -> KeyframeAction
     GroupAnimationFunction -> GroupAction
     PathAnimationFunction -> PathAction
     CustomAnimationFunction -> CustomAction
     Animation.animationFunction->action
(b)
     AnimationFunction -> AnimationEffect
     KeyframeAnimationFunction -> KeyframeEffect
     GroupAnimationFunction -> GroupEffect
     PathAnimationFunction -> PathEffect
     CustomAnimationFunction -> CustomEffect
     Animation.animationFunction->effect
(c)
     AnimationFunction -> AnimationEffect
     KeyframeAnimationFunction -> KeyframeAnimationEffect
     GroupAnimationFunction -> GroupAnimationEffect
     PathAnimationFunction -> PathAnimationEffect
     CustomAnimationFunction -> CustomAnimationEffect
     Animation.animationFunction->effect

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

etc...

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 / 
locallyReversed?

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 
direction
 > 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 
unavoidable)

 > 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