[web-animations] Web Animations minutes, 1 May 2014

Web Animations minutes, 1 May 2014

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

Agenda:
1. Time lag
2. Renaming
3. Script execution and timeline time
4. Computed values
5. Leveling
6. CSS Integration
7. Next WD


1. TIME LAG
===========
(Brian)

Discussion: 
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0075.html

I think we should go back to the time lag model but hide the timeLag 
member since it can be calculated.

Not sure I want to remove startTime. Maybe.

(Doug)

I'm happy if we just remove time lag, but I think we can remove 
startTime too.

The only additional information provided by start time is the ability to 
determine the sort order between players, and even then this is limited 
as we can't compare two players with the same start time.

The only additional functionality it provides is the ability to alter 
the sort order. Without start time there's still a limited ability to do 
this by moving the content to a new player.

An option would be to rename startTime to sortTime and have it be 
settable but otherwise unchanging, it's only effect would be on sort order.


 > Revert to time lag model but hide timeLag member and hide startTime 
too. We can add it back when we know which startTime is useful--the 
original one or the effective one.

It's possible to calculate the effective start time by comparing the 
player's current time and the timeline time.

If you need the original start time you could just record the 
"effective" start time before you do any pausing/limiting/seeking etc.


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

In a previous round of TAG feedback (I noticed it got updated recently) 
there was a question about what AnimationPlayer.source points to a 
TimedItem. The suggestion was, "Why not call the member timedItem?" (my 
paraphrase)

Suggestion A: rename TimedItem to AnimationSource. It fits with our 
other name "AnimationXXX" and suggests that these objects are really a 
static description of some timed effect which is how we want people to 
think about them. Then the AnimationPlayer.source member makes sense 
too. I also happen to not like "TimedItem" as a name. It's weird and I 
think it's the only thing left called "TimedXXX" (except TimedItemList 
which we would presumably also rename AnimationSourceList).

Doug: AnimationSource seems fine to me. The renaming below is scary.

Shane:
TimedItem: an item which is timed.
AnimationSource: a source of animations? I'm not sure this name is good.

TBH I don't think it matters much either way because you don't tend to 
talk about TimedItem explicitly. I don't really see a problem with 
AnimationPlayer.source pointing to a TimedItem either.

Brian: Suggestion B: The other idea I had (which I think you won't like) 
is the following naming:

(Shane: You think right ;-) Blobbing effect and Animation is a problem 
IMHO.)

   Animation (=TimedItem)
   GroupAnimation (=AnimationGroup)
   SequenceAnimation (=AnimationSequence)
   KeyframeAnimation (=Animation + KeyframeEffect)
   MotionPathAnimation (=Animation + MotionPathEffect)
   CustomAnimation (=Animation + EffectCallback)
   NullAnimation (=Animation w/ null effect -- needed? Make Animation 
non-abstract and use it?)
   (KeyframeAnimation and MotionPathAnimation might also share a 
PropertyAnimation super-interface for common storage of 
addition/accumulation parameters)

I think this is much easier to understand but not necessarily better.
- I don't think it necessarily blurs the timing vs animation distinction 
nor the distinction passed to arguments to the constructors (which are 
basically {anim params}, {timing params})
- I also don't think it pollutes more of the global namespace or 
increases API surface area--it simply shifts those things from the 
animation effect subclass to the animation subclass.

But it does lead to slightly blobbish classes. It means, for example, 
that you can't have an isolated animation effect that you could query 
independently. It might limit the possibility of, for example, making an 
effect built of other effects. So I'm not sure if this is the best 
design, but at least it is easy to understand.

As for AnimationPlayer.source, it would become AnimationPlayer.animation 
which I think is quite natural.

Brian: Suggestion C: Alternatively, we could just have:

   Animation (=TimedItem)
   GroupAnimation (=AnimationGroup)
   SequenceAnimation (=AnimationSequence)
   EffectAnimation (=Animation)

The problem is "new EffectAnimation" is kind of weird for something you 
probably do a lot.

e.g.
    new AnimationGroup([
        new EffectAnimation(...),
        new EffectAnimation(...)
     ]);

Doug: Whereas TimedItem or this Animation is something you almost never see.

Shane: Suggestion D: Do what the TAG recommended (AnimationPlayer.timedItem)
Shane: Suggestion E: Do nothing
Brian: Suggestion F:
   AbstractAnimation (=TimedItem)
   Animation (=Animation)
   AnimationPlayer.animation = new Animation() etc.
   AnimationPlayer.animation = new AnimationGroup() <-- Is that weird?

Doug: Should we make TimedItem a [NoInterfaceElement] ?

 > We're going to do a rename of TimedItem and maybe a rename of 
AnimationPlayer.source too.

TimedItem options:
AnimationBase
AnimationItem
AnimationSource

source options:
animation

 > Defer for now, but we've narrowed it down to roughly two options 
(TimedItem-> AnimationSource; or TimedItem->AnimationBase/AnimationItem 
and AnimationPlayer.source -> AnimationPlayer.animation)


3. SCRIPT EXECUTION AND TIMELINE TIME
=====================================
(Doug)

We had some feedback that the spec here is a little ambiguous. 'Script 
block' is not well defined, and 'script execution context' may not be 
either. Instead I think we should be talking about tasks.

Further, we don't define what the value of the document timeline is 
during tasks (other than the animation frame request callbacks), we only 
state that it must not change. I propose the following:

During the execution of a task, the value returned by the currentTime 
attribute of a document timeline will not change. The value will be:
-- If executing an animation frame request callback
---- a value consistent with the callback's context's time
-- Otherwise
---- the same as the value expected to be used in the subsequent sample

There's already some wording about the time used during a sample being 
consistent with animation frame request callbacks, but it seems strange 
to me:

"When performing this sample, the time value of each document timeline 
must be equal to the time passed to animation frame request callbacks 
for that browsing context."

It won't be equal because the timeline has a different zero, but it 
should be consistent.

Per another TAG issue, we should also state directly where sampling and 
the queuing of custom effect callbacks fits in to the RAF processing model.

Brian: I agree we need to address the case of setting up an animation 
that is synchronized to start with the *next* sample. Originally I 
thought we'd address that with playNextFrame()/playSoon() and 
animateSoon() etc. but if we can do without those, that's much better.

I don't want a situation where the order in which 
document.timeline.currentTime and window.getComputedStyle() are called 
produces different results. Basically, I'd like to see more detail.

 > Doug to spec this in a bit more detail (especially wrt getting 
computed values)


4. TAG REQUEST: COMPUTED VALUES
===============================
(Shane)

https://github.com/twirl/spec-reviews/blob/master/2013/10/Web%20Animations.md

We have an experimental API in the polyfill (branch: experimental) that 
does this. Want to take a look?
https://github.com/web-animations/web-animations-js/tree/experimental

 > Shane to write an email detailing what's actually in that.

There's also a request to expose time fraction. See next section.


5. TAG ISSUE: WRONG LEVELING
============================
(Shane)

It seems the TAG feels that we should have a separate 'computed' timing. 
I tend to agree (and was pushing for something like this last year).

WDYT about something like TimedItem.specified (== the provided timing 
object, no copy but freshly initializable from dictionary) and 
TimedItem.computed (== a dissociated computation of timing values)? I 
don't have a concrete proposal yet but I'd like to talk about where we 
roughly want to head.

Another alternative (more in the vein of what the TAG proposed):

TimedItem.timing = provided timing object, freshly initialized if 
provided as a dict.
(<something>.)?getComputedTiming(TimedItem) provides the computed timing 
values.
TimedItem has _no_ state.
It could be OK for this to be TimedItem.getComputedTiming() too.

 > Shane to send an email to public-fx with 2 proposals
(1) .computed
(2) getComputedTiming (on Timeline? on TimedItem?)

 > There's a question around where localTime belongs. Does it belong 
with timeFraction and currentIteration?


6. CSS INTEGRATION
==================
(Shane)

Early draft: 
http://rawgit.com/shans/98cb810920ac43876020/raw/b77db7529411066c9f3cdd36a52d0b98553525f9/Overview.html

Question about why does this only cover the API mapping and not also 
cover existing CSS Animations features? e.g. "CSS Animations Level 4" 
expressed in terms of Web Animations concepts.

 > Shane to talk to the CSSWG about this in Korea.

Brian somewhat unsure if we want to cover CSSKeyframesMap in first pass.

Dirk asks about synchronization feature.
Brian's suggestion: look at counters and counter resetting as a possible 
pattern to apply to group instantiation.
Shane: It doesn't belong in this spec, but could potentially be part of 
an integrated spec covering CSS Animations and this.


7. NEXT WD
==========

https://web-animations.etherpad.mozilla.org/todo

Just the following two items left:
* time lag stuff (resolved above, Brian to fix in spec)
* iteration composite stuff

 > Let's finish these off by the next telcon


Next meeting, TBD (Dirk to email)

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

Received on Thursday, 1 May 2014 08:29:26 UTC