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
