[web-animations] Web Animations minutes, 5 / 6 Sep 2013

Web Animations minutes, 5 / 6 Sep 2013

Present: Dean, Shane, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.QrHFsG$54jB/latest

Agenda:

1. Status updates
2. Feedback from Dean
3. Allow the children of groups with infinite duration to play as expected
4. Should time be frozen in JavaScript callbacks?
5. Fill control
6. Naming of <par> and <seq> (ParGroup and SeqGroup)


1. STATUS UPDATES
=================

Brian:
   - Added timing function chains to spec based on Steve's draft
   - Started writing up SVG integration:
     http://dev.w3.org/fxtf/web-animations/animation-elements.html


2. FEEDBACK FROM DEAN
=====================

Still concerned about API surface area. How can we expose this 
incrementally?

Possible staged release:
1. Element.animate -- but what does it return? An opaque Animation?
2. Element.getCurrentAnimations etc.
3. Timing groups

For a staged release, what should element.animate return? An opaque type 
might be quite frustrating to content. They will have to test if the 
object has particular properties available, etc.

Names in the global namespace:

We need to be careful when exposing so many new names into the global 
namespace.

e.g. Player
SeqGroup (especially if we rename it "Sequence")
Timing

Tension between safe names and long names. What do do?

 > Brian to mail the list


3. ALLOW THE CHILDREN OF GROUPS WITH INFINITE DURATION TO PLAY AS EXPECTED
==========================================================================

https://github.com/web-animations/web-animations-js/pull/466

The issue comes up in the following case:

document.timeline.play(new ParGroup([
   new Animation(foo, bar, {iterations: Infinity, duration: 2}),
   new Animation(foo, bar, {iterations: Infinity, duration: 3}),
]));

The duration of the ParGroup is Infinity, because it's calculated from 
the children.

You'd expect these animations to play forever, but currently they never 
start (because time never advances into the child over an infinite 
duration in the parent i.e. the timing function will never return a 
non-zero value)

The proposal is to ignore the timing function in these cases, and simply 
set the current time of an infinite-length element to be the scaled 
current time of the parent.

We think this actually is consistent behavior, not a special case.

 > Brian to fix in spec


4. SHOULD TIME BE FROZEN IN JAVASCRIPT CALLBACKS?
=================================================

https://github.com/web-animations/web-animations-js/issues/467

http://dev.w3.org/fxtf/web-animations/web-animations.html#script-execution-and-live-updates-to-the-model

- the 4th bullet point. Seems to be pretty clear from this that time 
needs to be frozen.

 > Steve, can you please follow-up the issue in github or here and point 
out which part is unclear?


5. FILL CONTROL
===============

Brian: I think it's really useful to have an animation fill to the end 
of a parent (ancestor?) container but no further.

Shane: +1. Isn't this just fill:forwards in the child and fill:none in 
the parent?

Brian: Actually the problem is that you want some things to terminate at 
the parent (but not before), and some things not to.

Shane: You can do this but it's not pleasant:

<par fill='forwards'> // parent group
   <par fill='none'> // group for things that stop at the parent
     ...
   </par>
   <par fill='forwards'> // group for things that don't stop
     ...
   </par>
</par>

Use cases:
- Cartoon animation -- you set up scenes and things that start during 
the scene fill until the end of the scene. e.g. you slide something onto 
the stage, manipulate it etc. then at the end of the scene it should 
just disappear off stage again
- Reverse transition -- you have a complex animation that performs some 
change and fills the result. Then you perform a reverse using a 
to-animation... no, actually, I forget where this was going

 > Will come back to this later once we have more concrete use cases


6. NAMING OF <par> AND <seq> (ParGroup AND SeqGroup)
====================================================
(Dean)

We're following SMIL naming here, but I don't think there is a need to 
do so. "Sequence" is a very clear and universally understood name. (Not 
sure what the equivalent of <par> is... "Group" seems ok to me although 
it is already being used).

 > Brian to include this in his mail


Next meeting: Fri 20 Sep 01:00 UTC @ https://etherpad.mozilla.org/UgIGNnOjfG
   Local time: 
http://arewemeetingyet.com/Sydney/2013-09-20/11:00/Web%20Animations
(Note that we will probably meet every second week from here onwards 
since the number of issues seems to have dropped)

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

Received on Friday, 6 September 2013 05:41:55 UTC