[web-animations] Web Animations minutes, 18 Dec 2014

Web Animations minutes, 18 Dec 2014

Present: Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.28977

Agenda:
1. Should we call it timingFunction instead of easing?
2. How are the CSS integration specs coming along?
3. Setting the currentTime / playbackRate of AnimationTimeline
4. Distance when used values cannot be calculated
5. Adding AnimationPlayer.start() and returning Promises
6. Renaming AnimationPlayer.source to AnimationPlayer.animation?


1. SHOULD WE CALL IT timingFunction INSTEAD OF easing?
======================================================

Last time we ended this discussion with:

 > Shane to suggest to CSS WG they add aliases
 > Shane to coordinate with Tab / Paul Irish / someone to collect data 
from developers about their preference: consistent naming or short naming

To summarise the naming differences:
* animation-timing-function vs easing
* animation-iteration-count vs iterations
* animation-fill-mode vs fill (this one might be ok because SVG uses 'fill')

 > Shane/Doug to chase up dev-rel guys to get the data


2. HOW ARE THE CSS INTEGRATION SPECS COMING ALONG?
==================================================

Some discussion about what the spec should hold.

Suggestion: take current spec text, stick previous draft of how 
integration works on the end then gradually smooth the two out.

Q: Is shipping getAnimationPlayers blocked on this spec?

Yes. But we could consider a filter if we really have to (i.e. don't 
return CSS Animation / Transition objects until that spec stabilizes).

Discussed the mechanics of splitting the spec into two levels. Brian is 
hoping to do this in January.

Discussed transition-delay, is it the same as backwards fill? Needs 
further discussion.


3. SETTING THE currentTime / playbackRate OF AnimationTimeline
==============================================================

This is useful for testing / devtools. Some concern about exposing it to 
Web content. Authors may be tempted to using this for playback control 
when normally they should use players for this. Why? Because 
manipulating the timeline will affect *all* animations on the page 
including any seemingly innocent transitions used as UI flourishes. In 
particular we don't want authors pausing the global timeline otherwise 
all of a sudden transitions etc. don't work and their whole app breaks 
down unexpectedly.

How to make obvious to authors the global impact of their actions if we 
allow this?

Some suggestions: Only make these properties available for timelines 
other than the document timeline.

Currently browsers can implement this as a privileged API. We can 
investigate exposing it to Web content in level 2. Would be good if such 
privileged APIs could be exposed for cross-browser testing.


4. DISTANCE WHEN USED VALUES CANNOT BE CALCULATED
=================================================

 From the mailing list:

http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0119.html

 > If you can't calculate a used value for any of the paced property 
values, it falls back to distribute for all pairs of values.


5. ADDING AnimationPlayer.start() AND RETURNING PROMISES
========================================================

While implementing AnimationPlayer.ready I (Brian) went over why 
AnimationPlayer.play() doesn't return the ready promise (Answer: because 
authors might assume it returns a promise that resolves when the 
animation finishes).

Cameron suggested perhaps we could do:

   AnimationPlayer.start() [returns ready promise], and
   AnimationPlayer.play()  [returns finished promise]

Shane:
This makes sense for start()
play() returning the finished promise may encourage chaining of animations.

Does start() always set currentTime back to the start?

Brian: Or does it simply unpause without the rewinding?

Shane likes the idea of composing the different functions from more 
primitive actions (e.g. reverse() is just set playbackRate + play()). 
What if play() could be build up from start() + currentTime adjustment 
when limited.

 > Shane to talk to some others and get some more feedback about whether 
play() should return the finished promise or if that will encourage a 
suboptimal approach to chaining animations

[ Brian: Later thought after the meeting: start() sounds like the 
opposite of finish() which suggests it seeks back to the start. Perhaps 
resume() is better? ]


6. RENAMING AnimationPlayer.source TO AnimationPlayer.animation?
================================================================

One of Mozilla devs yesterday expressed surprise at the source property 
and "source content" concept. He very much expected it would be the 
"animation" property and "source animation".

We named it source because it is supposed to be able to point to groups 
or media items too. But note that all of them are generically called 
"animation nodes" and groups are called "animation groups". When we 
introduce media items, we might called them "animation media" or 
something, who knows. And it is an "animation player" so it makes sense 
that it has an "animation" property.

 > Doug to collect data on this. What do other people think?


Topics for next time:

* Promises again (re: finished event)
* Additional input for keyframe effects?

Next meeting: TBD, January 2015 sometime

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

Received on Thursday, 18 December 2014 06:51:37 UTC