Web animations minutes, 6 / 7 December 2012

Web animations minutes, 6 / 7 December 2012

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.PMFvlHwAFHu/latest
Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles

Agenda:

1. Status update
2. Animation timelines and triggers
3. Integration with media

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

Brian:
* Working on KeyframeAnimation ctors and related bits (still a work in 
progress)
* Architecture design work

Shane, Doug, Steve:
* tests in the polyfil
* paths
* time sources

2. ANIMATION TIMELINES AND TRIGGERS
===================================

Brian:

As I understand the two proposals we have:

a) A simple time source is strictly a root-level thing. It's basically 
like a group but without the ownership semantics (i.e. keeps its 
children alive forever). Groups, implement the same interface and add 
ownership semantics and scheduling for their children 
(par/seq/mediacontroller-style-sync).

b) Animations can have BOTH a parent group and a time source and there 
is a defined method to manage the two so that the time source gets 
applied inside the group's time window. In the common case, an 
animation's time source is its parent group.

Let's consider use cases for (b).

-- Use case 1: A primarily UI-driven "animation" with timed parts --

Description: The animation is driven by scrolling but when you reach 
certain key points animations are triggered. For example, a comic where 
as you scroll the characters move, but when the hero's fist connects 
with the villain's cheek,  a caption saying "Blammo!" springs out with a 
starburst in the background. This part animates over 0.5s regardless of 
progress of the scrollbar. However, if you're scrolling really quickly 
and scroll past a certain threshold the animation should jump to the end 
or be cancelled (presumably defined by the fill mode).

Analysis: This fits really nicely with (b). You have time windows 
controlled by the scrolling that set out when the timed animations can 
play. When you scroll fast you hit the end of the window and that could 
be used to fast-forward the timed animations to their fill state.

Note that this could currently be achieved with script by simply 
triggering independent animations whose time source is the document time 
source when we hit the "begin" event for the parent group. Likewise the 
"end" event could be used to fast-forward. However, a declarative 
solution is likely preferable for this use case since it does appear to 
be something one might expect an epub publisher to produce. That said, a 
simple script framework could interpret some suitable markup and realise 
this use case using the Web Animations API and that might even be a 
preferable approach given that this use (mixing UI-driven time sources 
and clock-driven time sources) is probably rare.

Shane raises issue of jank involved in script-based triggering.

Agreed declarative solution for this is better in the long-term.

-- Use case 2: A primarily time-driven animation with UI driven parts --

Description: There is an interactive cartoon which plays by itself but 
requires the user to perform certain actions in order for it to 
continue. e.g. drag the door open to enter.

Analysis: Whilst again, (b) seems to meet this case well, my impression 
of this sort of use case is that it will get complex really quickly 
(e.g. you'll have choose-your-own-adventure style interactions) and 
you're not going to be able to do it without some script. So long as you 
permit the possibility of using script we can already do all this.

Shane: I agree - this isn't a great fit for either (a) or (b) unless the 
interaction is very simple. State machines will help us a lot here, 
though - and once they do, (b) is important.

-- Use case 3: Momentum the easy way --

It's probably possible to achieve momentum using a purely UI-driven 
approach by simply controlling the values you return from 
ScrollTimeSource.currentTime. That might be a bit tricky and might mean 
you can't re-use the time source for multiple animations?

Shane: Script is the killer here, especially on mobile platforms. Or do 
you mean defining specific behaviours in the spec? I think we're going 
to have to do that regardless of which approach we take.

Brian: Yes, I mean you could define a TimeSource in the spec that 
returns momentum-weighted values for, e.g. ScrollTimeSource.currentTime. 
Not from script.

Brian: Regarding re-using time sources, I think it's reasonable to 
require independent time sources for animations that behave 
independently. That is, you don't simply have one time source 
representing vertical scroll, but provide the possibility of creating 
several such time sources, each offering their own momentum. You'd 
define the notches on the time source not the animations.

Shane: Agreed. I don't think momentum the easy way is the right use case 
for (b) - if anything, (b) give you "momentum the flexible but 
complicated way" (i.e. supporting post-user-interaction animations that 
don't neatly fit into whatever declarative time sources we provide).

On the other hand, time source and time source transformation makes it 
easier to define the momentum time sources, because they're adapters 
over the horizontal or vertical scrolling time source.

Going forward: For me (Brian), the question is what is the minimum we 
can include in v1 without compromising our ability to support these kind 
of use cases in the future? Can we start with (a) and incorporate 
something like (b) in the future?

My suggestion is we do pretty much (a), or, in fact, even less:
* Define a TimeSource interface with the single member:
     attribute double currentTime;
* Replace TimedItem.parentGroup with TimedItem.parentTime
* Make AnimationGroup implement TimeSource
* Make MediaController implement TimeSource?
   -- this, amazingly, might just work since MediaController includes 
the following attribute:
      attribute double currentTime;
   (it's settable, it's in seconds, and it matches the naming in our API)
   (We could extend media controllers to point to a parent time source 
or we could just say that for now they always use the document time source.)

Shane: this is more or less what I wanted to do for media element 
synchronization. So: yes!

Brian (contd.):
* Introduce a global instance of time source that has its zero time as 
the moment the document begins (this definition needs work since I want 
to revisit the autoplay behaviour)--and when you try to set it it throws 
a NoModificationAllowedError exception
* It's tempting to make Animation implement TimeSource but does that 
make sense to slave an Animation to another Animation?
* That's it. No custom time source or anything like that. Yet.

In the future, we can define additional types of time sources and they 
should plug into the model just fine. It could even be a separate spec 
(a module), not a revision of Web Animations.

Shane: this sounds like a great idea.

Brian (contd.):
I wonder if you could achieve (b) by wrapping up the intersection of the 
time window and time space by adding an intermediate time source?

e.g. for use case 1
   ScrollTimeSource (orient:vertical)
     Par (start: 0, end: 3)
        ...
     Par (start: 3, end: 5, id)
        ...
        TimeSource (start: 0) <-- time-based
            Anim (prop: height, dur:1s) <-- time-based

The point is, I think we can leave this out entirely and plug it in 
later. The main issue is probably naming. If we expect an animation in 
future to possibly have both a parent group and a time source then we 
might not want to use 'timeSource' to represent what later be just the 
'parentGroup'.

But I think it's ok. We can use 'timeSource' for now and later either 
use the approach above of adding intermediate time sources or just add 
'primaryTimeSource'? 'playTimeSource'?

Shane: In case I haven't already made it abundantly clear, I'm very 
happy to leave stuff out as long as we've thought of the long term 
implications of where we are going and how to get there. If we can 
capture the spirit of (b) by nesting TimeSources then sure, let's do it. 
I'd like to make sure we can before committing to this path though. It 
would require the time window from the parent group being passed through 
the time source, which seems OK as time sources need to provide time 
windows to their children anyway.

 > Summary of discussion so far:

- Discussion centres around whether we should separate the concepts of 
group ownership and time source at the API.
   -- one view is to make these separate concepts from the beginning and 
children of groups just happen to have derivations of the same parent by 
default in terms of time
   -- the other view is to conflate the two concepts for the sake of 
simplicity--for children of groups your parent group is your parent time 
source because you can't specify otherwise

Brian (contd.):

Naming:
* I'm leaning towards Timeline since I do often hear people say things 
like, "I want to tie this animation to the video's timeline"
   -- so perhaps it's not so weird to think of a parent timeline?
* Also, HTML5 has: "Each MediaController also has its own defined timeline."
* Then you'd have TimedItem.parentTimeline which makes a little more sense.

Compare
   anim.parentTime.currentTime
   anim.parentTimeline.currentTime

Although
   anim.timeSource.currentTime
isn't bad either

What about
   anim.timeline.currentTime ?

Timeline also has the advantage that if there is a CSS property for this 
it's probably going to be animation-timeline and not animation-timesource.

3. INTEGRATION WITH MEDIA
========================
(Brian)

Summary:
-------------

* Subclassing groups from MediaController seemed attractive but that 
doesn't fix the outstanding issues regarding pausing/reversing/seeking 
children of a repeating par group or a seq group.

 > We are all currently leaning towards keeping the Media subsystem of 
HTML at arms length rather than trying to merge the two.

* Summarising MediaController:
  -- similar to the idea of a "loose" par container we have previously 
raised
  -- children can be paused independently
  -- unpausing a child makes it catch up to the group time
  -- seeking a child throws an InvalidStateException
  -- setting playbackRate on child (closest thing to reversing) is 
ignored and parent playbackRate is used instead
  -- the group itself can't be repeated or reversed
  -- its playback rate can be set and governs all children
* Comparison to <svg>
  -- <svg> children should be able to be seeked independently
  -- <svg> children should be able to be paused independently without 
catchup behaviour
  -- <svg> children should be able to have their playback rate adjusted 
independently
  i.e. it doesn't map so well to <svg>

* The investigation into MediaController set out with the hope that it 
might provide a path to fixing the current complications involved in 
pausing/reversing/seeking descendent items of a repeating par group or a 
seq group but that no longer appears to be the case. We have to solve 
those issue some other way.

* It seems attractive to simply remote such operations on descendent 
elements to their parents (and so on up the chain) however this appears 
difficult for the case of seeking due to the fact that timing functions 
that can currently be applied to such groups are not always invertible

 > On further consideration this may be more complex, less intuitive, 
and less powerful.

* Pausing can probably be remoted fairly easily but whether we do this 
or not depends on how see address seeking since we might want to be 
consistent there

* Current options for addressing seeking include:
   - Restrict the timing functions allowed on such sync groups (i.e. 
basically don't allow timingFunction) so we can remote seek operations 
up the chain
   - Allow a kind of local seek that gets reset when the current 
iteration of the parent changes
   - Simply disallow seeking children of a sync group (by either 
throwing an exception or just ignoring the change)
      - This is consistent with HTMLMediaElement

 > Discussed the notion of having a fixed time window for each timed 
item. The window is established based on the 'default' timing parameters 
for the item. 'Live' changes to the item such as pausing and reversing 
do NOT affect the calculation of the time window. This provides fairly 
easy-to-reason-about behaviour for the cases when we have children in 
repeating groups.

 > The document time sources establishes an infinite time window for its 
children.

 > 'Live' state does NOT reset when the parent group enters another 
iteration. If you pause animation A during iteration 1 of the parent 
group, it will still be paused when you enter iteration 2.

Needs further investigation

Next meeting: Mon Dec 10, 17:30 PST / Tues 11 Dec 12:30 AEDST / Tues 11 
Dec 10:30 JST @ https://etherpad.mozilla.org/7Qo6P4kYyD

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

Received on Friday, 7 December 2012 04:57:48 UTC