- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 01 May 2014 17:28:53 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
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