[web-animations] Web Animations minutes, 27 Mar 2014

Web Animations minutes, 27 Mar 2014

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

Agenda:

1. Getting rid of time lag
2. More renaming
3. Publishing next WD
4. Re-thinking group types


1. GETTING RID OF TIME LAG
==========================

Carrying over from Tokyo F2F:

* Time lag is an extra concept
* We currently use it so we can preserve the start time for the purpose 
of sorting
* If we were to just adjust the start time when pausing/seeking etc. 
then you would get weird effects like the following:
    -- two animations are targetting the same element and one is 
"winning" because it started later
    -- you pause the "loser" and the unpause it and it starts winning 
because now it has a later start time
* We could get around this by simply storing the start time whenever you 
set it directly (i.e. not by pausing etc.) and use this stored value of 
the start time for sorting

Doing a quick survey of other animation APIs, most don't report the 
start time at all (specifically CoreAnimation, QML, Android, 
HTMLMediaElement don't; GSAP does). So perhaps we can drop start time 
from the API? The start time under the proposed behavior above is 
calculatable as simply player.timeline.currentTime - player.currentTime

The model still needs to track the initial start time of the player for 
sorting purposes.

 > Brian to try working this into the spec


2. MORE RENAMING
================
(Brian)

I'm still not comfortable with animation players. Pretty much everyone I 
talk to gets stuck on that point. "Why do we need players?"

(Shane)
Just point them at 3.1.1. in the spec. That is why :)

(Brian)
I think it's partly a naming thing. For me, elem.getAnimationPlayers() 
seems weird somehow.

(Shane)
I've had the opposite experience. People like the separation between 
animation model and control. I'd also note that while we've had plenty 
of public feedback on public-fx@ from a variety of sources, none of it 
has mentioned that Players are awkward. The closest was Mike's feedback 
about pointer loops, and he certainly wasn't questioning the naming of 
or need for players.

(Brian)
Two options keep cropping up:

A) AnimationPlayer -> Animation

We've thought about this a few times. What would it look like?

   Animation -> AnimationSource
   AnimationGroup/Sequence -> AnimationSourceGroup/Sequence
   AnimationPlayer -> Animation
   TimedItem -> AnimationSourceItem?
   (TimedItem.player -> TimedItem.animation, if we keep it)
   (not sure about MediaItems)
   Animatable.getAnimationPlayers -> getAnimations (or getCurrentAnimations)

* AnimationSource vs AnimationSourceItem is a bit weird but authors 
never need to know about AnimationSourceItem
   The thinking was simply that it would be neat if Animation.source 
pointed to an AnimationSource
* AnimationSourceGroup is pretty long
* Somehow elem.get(Current)Animations seems a lot nicer to me than 
elem.getAnimationPlayers


B) Timeline -> TimeSource, AnimationPlayer -> Timeline

People seem to very naturally bring up the terms "timeline" and "time 
source". I hear it over and over again.

What would it look like:

   Timeline -> TimeSource (Clock?)
   Document.timeline -> Document.clock
   AnimationPlayer -> Timeline
   AnimationPlayer.source -> Timeline.content
   AnimationPlayer.timeline -> Timeline.source ? (timeSource?)
   Animatable.getAnimationPlayers -> getAnimationTimelines

So you'd say:

   document.clock.play(animation);
   document.getAnimationTimelines()[0].pause();

* It is quite different to the idea of timelines in history textbooks 
which are monotonically increasing since you can seek/pause/speed-up our 
timelines. However, in discussions I've had most people seem ok with 
this. Perhaps they have a very postmodern education.

For gesture-based timing, you'd represent that as a time source. 
Likewise, you could base timing on a media element by treating it as a 
time source.

For SVG, we could make the SVG fragment timing a special kind of time 
source that has some limited playback control. Alternatively, we could 
allow nesting timelines and represent the SVG fragment as a timeline. 
Nesting playback control is only really problematic when you have 
repetition and groups. In other words, Timeline.source could be a union 
type (TimeSource or Timeline).

(Recap: The reason SVG is special is that SVG defines an API for 
pausing/seeking all the SVG animations in an SVG document fragment. 
Also, absolute times within that fragment are relative to the start time 
of the fragment. At the same time we want to offer more fine-grained 
playback control for SVG so you can pause parts of the fragment, for 
example. This suggests two levels of playback control.)


 > Of the above approaches, the second has more promise but is still a 
bit awkward. Calling a thing with play control a timeline is a bit odd. 
And document.clock.play is weird since a clock is really a passive object.

We'll leave things as-is for now and see what other feedback we receive 
as the API gets more exposure.


3. PUBLISHING NEXT WD
=====================

TODO list: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.wQ9q6/latest

Getting close.


4. RE-THINKING GROUPS
=====================
(Brian)

If we split the spec in two, we have more opportunity to tweak groups. I 
think their simplicity is great--it's easy to understand and can cover a 
lot of cases. It also has parallels in most animation APIs.

However we've noticed shortcomings in our layout primitives from time to 
time. Also, we've sometimes made joking comments like, "we need flexbox 
for time" and so on.

I wonder if it would be more Webby and useful to setup groups in a way 
that has more parallels with CSS layout?

That is, instead of a discrete set of group types, simply have 
AnimationGroup and then layout properties on *children*. At a first pass 
it could be just "layout: sequence" (= display: inline?) and "layout: 
normal" (= display: block?).

I'm not sure. I can see absolute positioning as being useful, or at 
least mixing modes within a group. It probably depends a lot on being 
able to find parallels that are close enough to CSS that Web authors can 
transfer their knowledge, whilst avoiding the complexity of CSS layout 
that makes it such a pain to use.

We'd also need some means of easily setting up a sequence so you didn't 
have to explicitly set "layout: sequence" on each child.

I'm really not sure if this approach makes sense but if we split the 
spec into two levels we could have a bit more time to think about it.

(Shane)
I definitely like the idea of being able to think about Groups a bit 
more. I'm not sure we need to split them out as another level (I'm not 
opposed to this, but looking through the specification I'm having 
trouble working out how we would do it - for example, do we define 
TimedItem now, or not? It's useless without Groups, but if we don't 
define it will it be easy to add it later?)

I think that proceeding with our phased implementation plans will be 
quite effective here. For example, Doug worked out a really nice 
technique for using native animations with polyfilled groups that 
removes most of the work that the polyfill does. In other words, 
releasing nothing more than the minimal set we defined at the f2f allows 
the polyfill to run pretty close to native performance (although without 
any compositor acceleration). This would give us a *lot* of leeway to 
experiment with different Groups in the polyfill.

(Doug)
I think we could keep AnimationGroup but defer AnimationSequence. We 
have plenty of options (adding logic to AnimationGroup, introducing 
subtypes, or layout parameters on children). It shouldn't be hard to do 
high-fidelity polyfills of other grouping mechanisms on top.


 > Agree that groups aren't ready yet and we want to ship without them 
initially. Unsure what process is best for that. For the time being we 
would like to leave groups in the spec but if we later need to move 
further on the recommendation track and groups are holding us back we 
will split them out then.

Regarding other layout ideas, we think the group + sequence combination 
is still a useful first step. We can add other concepts like "make this 
line up with that" (similar to syncbase timing but still preserving the 
concept of a timing tree, not a graph), absolute positioning, flex etc. 
later after thorough investigation and based on use cases that come in.



Next meeting: Mon 14 Apr 22:00 UTC (or 21:00 UTC if that is better for Dirk)
   Local time: 
http://arewemeetingyet.com/UTC/2014-04-14/22:00/Web%20Animations

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

Received on Friday, 28 March 2014 01:34:16 UTC