- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 06 Dec 2013 11:29:13 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 5 / 6 Dec 2013 Present: Alan, Doug, Shane, Steve, Brian Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.XgDJWjXpD2w/latest Agenda: 1. Status updates 2. Interpolation of images 3. Player changes 4. Naming of timing groups 5. Renaming PathAnimationEffect to MotionPathEffect? 6. Factoring out paced timing as separate to easing 1. STATUS UPDATES ================= Brian: - Player changes (see below) - Presentation at html5j: http://brian.sol1.net/svg/2013/12/04/web-animations-html5j-2013/ 2. INTERPOLATION OF IMAGES ========================== http://dev.w3.org/fxtf/web-animations/#the--image--type The spec says to use CSS4 Images - http://dev.w3.org/csswg/css-images/#cross-fade-function - but this requires the intepolation fraction to be limited to [0, 1]. We should add that the fraction is clamped to this range before using the CSS4 Images algorithm. > Actually, we should just replace the <image> section by saying, "Interpolation is defined in CSS4 Images" 3. PLAYER CHANGES ================= The spec text is not quite right. Alan has provided some excellent feedback and Brian will try to fix the spec ASAP. Some discussion about whether Element.animate() should return an Animation or a Player? Brian still feels like Animation is right, but others are not sure. Use cases include: i. Building up groups: new TimedGroup( [ elem.animate(...) ] ); vs. new TimedGroup( [ elem.animate(...).source ] );, or allowing Players to be passed into TimedGroup lists.. ii. Adding onend listener: elem.animate(...).onend = ... vs. elem.animate(...).source.onend, or adding events to Players, or Object.observe()? iii. Modifying timing var anim = elem.animate(...) anim.specified.delay = .... vs. var anim = elem.animate(...).source; anim.specified.delay = ... On the other hand: elem.animate(...).pause() // build a paused animation vs elem.animate(...).player.pause() elem.animate(...).currentTime = ... // CSS-style "scrubbing" vs elem.animate(...).player.currentTime = ... > Still not entirely sure what Element.animate should return. Feedback is welcome. Discussed events with regard to where onend lives. If element.animate returns a player we should probably have onend on player as well which means we need to define player events. We will return to this discussion later when we try to solve events once and for all. 4. NAMING OF TIMING GROUPS ========================== (Brian) Original thread: http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0115.html Follow-up threads: http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0124.html http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0123.html Current proposals: A. SyncGroup and SequenceGroup (elements: <sync> and <sequence>) - Clear but too similar to each other? - 'Group' naming is generative and emphasises that they are the same kind of thing c.f. http://doc.qt.digia.com/qq/qq13-apis.html#theartofnaming "Identify groups of classes instead of finding the perfect name for each individual class. For example, All the Qt 4 model-aware item view classes are suffixed with View (QListView, QTableView, and QTreeView), and the corresponding item-based classes are suffixed with Widget instead (QListWidget, QTableWidget, and QTreeWidget)." B. TimedGroup and TimedChain (elements: <timedgroup> and <timedchain>) - Clear and distinctive - Not so generative, not quite so clear that they are the same kind of thing - What do you call them collectively: "timed groups" vs "a regular timed group" ? - Should it be TimingGroup / TimingChain ? TimedGroup / TimedChain ? TimeGroup / TimeChain ? (Brian: I accidentally got this wrong in my presentation and called it TimingGroup/TimingChain although the original proposal was TimedGroup/TimedChain) Other permutations: * SyncGroup and ChainGroup ? * TimedGroup and TimedSequence ? Some concern that TimedSequence is longer than TimedChain and not necessarily significantly clearer. In light of that TimedGroup / TimedChain seems preferable. Brian somewhat uncomfortable with "Timed" particularly in element syntax "timedgroup" and from a non-English speaking background point of view, "Time" and "Timing" are more simple/familiar. 5. RENAMING PathAnimationEffect TO MotionPathEffect? ==================================================== PathAnimationEffect sounds like it animates a path's points, not moves an element _along_ a path. Also, unlike KeyframeAnimationEffect, you actually *do* type PathAnimationEffect. Suggested renaming: - AnimationEffect remains the same as the common base class - PathAnimationEffect -> MotionPathEffect (based on the common concept of a "motion path" as used in, e.g. Office, After Effects etc.) - KeyframeAnimationEffect -> KeyframeEffect - CustomEffect remains the same Disadvantage: Naming no longer distinguishes betweens custom effects and animation effects (PathAnimationEffect and KeyframeAnimationEffect inherit from AnimationEffect and are composited according to the prioritisation outlined in the model but custom effects are run later). However, the name "custom effect" does suggest special handling. > The renaming sounds good. 6. FACTORING OUT PACED TIMING AS SEPARATE TO EASING =================================================== The idea here is that pacing is a separate property applied to space out the animation values (be they keyframes or points on a path). Easing is applied *after* that. That allows you to pace a path and then ease the entire motion whereas currently you can't do that. For keyframes you'd have three modes: * Keyframes are evenly distributed * Keyframes are distributed so that the rate of change of a given property is constant (for properties where this makes sense) * Keyframes have their positions specified explicitly If the author specifies both "paced" and "explicit offsets" we need to determine the behaviour. Lots of edge cases to consider. For example, is it useful to be able to pace an effect in general but specify absolutely the offset of just one value? The idea that pacing should always override any offsets is attractive--would let you switch on paced timing globally without having to unset all the offsets. What do we do when there are no keyframes with the paced property? This seems OK - you just get even distribution, as when any keyframes are missing that property. Need to decide which property to pace on. This would be a flag set at the effect level. Is there a default value? The first property in the first keyframe? From an API point of view, we could change: [Constructor (OneOrMoreKeyframes frames, optional CompositeOperation composite = "replace", optional AccumulateOperation accumulate = "none")] interface KeyframeAnimationEffect { ... To: [Constructor (OneOrMoreKeyframes frames, optional EffectOptions options)] interface KeyframeAnimationEffect { ... dictionary EffectOptions { CompositeOperation composite = "replace"; AccumulateOperation accumulate = "none"; DOMString distribute = "equal" ? // Other options being "paced(left)" etc. ? } Still some uncertainty about whether pacing should always win since in the above arrangement "equal" would only apply when there are no offsets but "paced(left)" would always apply. Needs more thought. Next meeting: Fri 13 Dec 0:00 UTC @ https://etherpad.mozilla.org/3eVWyRLwbN Local time: http://arewemeetingyet.com/Sydney/2013-12-13/11:00/Web%20Animations Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 6 December 2013 02:29:43 UTC