- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Wed, 23 Jan 2013 11:12:41 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web animations minutes, 22 / 23 January 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.sNox0X6XAmx/latest Present: Dmitry Baranovskiy, Shane Stephens, Douglas Stockwell, Brian Birtles Agenda: 1. Status update 2. Playback control progress 3. Timing object 4. Interpolation modes 5. Other timing functions 6. Multiple target elements 7. Grouped animation effects 8. Draft face-to-face schedule 1. STATUS UPDATE ================ Brian: * Drawing pictures https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/img/time-calculations.svg https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/img/active-duration-calculation.svg * Playback control research for SVG (see below) * Timing object thoughts and proposal (see below) * Spec edits - Rename TimedItem.targetElement to target - Define states for timed items - Add Document.getCurrentAnimations() - Add Element.getCurrentAnimations() - Remove TimingGroup.getActiveAnimations() Shane: * Not much since last meeting, just reading Brian’s documents 2. PLAYBACK CONTROL PROGRESS ============================== Any further thoughts? One issue that has arisen is how to approach SVG which seems to require two levels of play control: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Play_Control_Review#Update_.233 Discussed this document (specifically, update 3 regarding SVG play control). We all think that: ① the specifics of nested pause/play behaviour is probably not being relied on, so we have an opportunity to make this behaviour consistent across the browsers ② we can implement any of these behaviours relatively easily within the Web Animations framework ③ probably we should go with Opera’s approach as the most useful that is compliant with what is specified (Specifically this means essentially flattening nested SVG elements for the purposes of time containment and remoting calls to pause etc. on nested SVG to the root SVG element) ➙ Remainder of discussion regarding play control deferred to Web Animations F2F in Sydney 11 – 15 Feb 3. Timing OBJECT ================ Any further ideas? Dmitry? Defer to F2F? Some thoughts: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Shared_Timing Brief discussion of CSS integration — should CSS have the following properties: ① should CSS-derived animations be editable from JavaScript? ② if so, should it be possible to revert a CSS-derived animation back to its original, CSS-only state? Yes to ① and ② means we need _some form_ of timing sharing (or at least part of it). It’s possible we can just expose this through CSS integration rather than as part of the full Web Animations spec. It’s also possible to accept ① and not ② for now. Whether either of these possibilities is desirable is a matter for discussion. ➙ Remainder of discussion regarding the Timing object and sharing deferred to Web Animations F2F in Sydney 11 – 15 Feb 4. INTERPOLATION MODES ====================== (Brian) Just a curiousity, if we wanted to support, say, interpolation of colours in HSL space as well, where would we hang that off the API? There’s two parts this: ① automatic rules for interpolating between any two of a given multi-specced value type (color, length, transform, etc.) ② manual specification of rule choice to provide for specific effects Doug: Similar to this, we might want to support requesting non-numeric interpolation (just snapping to the closer keyframe) for types that are normally interpolable. This fits under point ②. Brian: This is similar to SVG’s calcMode attribute Shane: Looks like we can support Doug’s request using per-keyframe timing functions that are steps at 0.5. ➙ Agreed it doesn’t look like ② is needed for version 1 and that we can add this functionality to the API later if it proves necessary (e.g. by attaching an Interpolator to AnimationEffect that subclasses call out to). Until then, authors can use CustomAnimationEffect to produce specialised interpolation. One case to bear in mind is SVG’s color-interpolation property: http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty which applies to animation of colours. Another thing to keep in mind is that CSS always interpolates in premultiplied color space. Do we want to do this always too? Or provide more flexibility? It seems like SVG might be not premultiplied. Outcome: we don’t need to update the architecture but we’re going to need to pay attention to detail when specifying how colors are interpolated. 5. OTHER TIMING FUNCTIONS ========================= (Brian) In reviewing other APIs I notice some of them have a *lot* of timing functions on offer, e.g. QML: * Easing -- 42 different types!!! Including "OutInBounce", "InOutElastic" etc. http://qt-project.org/doc/qt-4.8/qml-propertyanimation.html#easing.type-prop each types can also be tweaked by specifiying: overshoot, amplitude, period (not all properties apply to all types) * Smoothing (similar to our merging?) * Spring Raphael: * linear, easeIn, easeOut, easeInOut, backIn, backOut, elastic, bounce http://raphaeljs.com/reference.html#Raphael.easing_formulas Dojo Toolkit: • linear, quadIn, quadOut, quadInOut, cubicIn, cubicOut, cubicInOut, quartIn, quartOut, quartInOut, quintIn, quintOut, quintInOut, sineIn, sineOut, sineInOut, expoIn, expoOut, expoInOut, circIn, circOut, circInOut, backIn, backOut, backInOut, elasticIn, elasticOut, elasticInOut, bounceIn, bounceOut, bounceInOut http://dojotoolkit.org/reference-guide/1.8/dojo/fx/easing.html CA: * linear, easeIn, easeOut, easeInOut, default, bezier https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CAMediaTimingFunction_class/Introduction/Introduction.html#//apple_ref/occ/cl/CAMediaTimingFunction jQuery: * swing, linear Most others defined by plugins, e.g. http://api.jqueryui.com/easings/ Android: * AccelerateDecelerateInterpolator, AccelerateInterpolator, AnticipateInterpolator, AnticipateOvershootInterpolator, BounceInterpolator, CycleInterpolator, DecelerateInterpolator, LinearInterpolator, OvershootInterpolator http://developer.android.com/reference/android/view/animation/Interpolator.html WPF: * BackEase, BounceEase, CircleEase, CubicEase, ElasticEase, ExponentialEase, PowerEase, QuadraticEase, QuarticEase, QuinticEase, SineEase http://msdn.microsoft.com/en-us/library/ee308751.aspx Note, ElasticEase uses parameters: 'oscillations' and 'springiness' d3: * linear, poly(k), quad, cubic, sin, exp, circle, elastic(a, p), back(s), bounce https://github.com/mbostock/d3/wiki/Transitions#wiki-d3_ease mathBox: * in, out, default https://github.com/unconed/MathBox.js/blob/master/src/Animator.js#L280 Most support custom functions. We are concerned about calling out to script during a sample for this. Perhaps we can accommodate timing functions that aren’t pre-defined by simple linear interpolation? Proposal: spin Timing Functions off as a seperate specification. Ship v1 of Web Animations with just enough timing functions for CSS and SVG support. Seems to be agreement on this. Done. We’ll keep the basic timing functions inside the Web Animations specification for now, until Timing Functions reaches maturity. 6. MULTIPLE TARGET ELEMENTS =========================== A while ago we decided that in the future we probably want Animation.targetElement to be able to target a list of elements in the future and so we should rename it to 'target'. That's fine, but it probably deserves a bit more thought. For example, *if* we do that, how could you cancel all animations that apply to element A without having side effects? Maybe we should define cancelling in terms of removing an element from the target property of all animations? And is there are use case for being able to say "cancel all animations targetting A but keep their current value (i.e. freeze them)"? Or "cancel all animations targetting A but first fast-forward to the end"? (A number of APIs have a "finish" method for this)? Anyway, this doesn't need to block FPWD but I'm just flagging it as an issue for now. Another related issue is *if* we allow target to refer to multiple elements, this might influence the way we map SVG to Web Animations. For example, if version 1 of Web Animations Core only supports a single target BUT version 1 of Web Animations SVG Integration allows <animate select=".cloud" ... /> (and this is the current state of play), then SVGAnimationElement.getActiveAnimations() would probably return one Animation per matched target. However, once target can support multiple elements it would be far more natural to return one animation with multiple targets but we would be unable to do this if content already expects one per animation. Then, of course, if <animate select=".cloud"> was defined such that when a newly matching element was found it started from the beginning, then in that case, the one animation per target would make sense. One option might be to simply delay <animate select=".cloud"> until the API catches up. Also, how does event dispatch work with multiple targets? What is the propagation chain? Shane’s proposal: templates make much more sense because they: ① allow cancellation to be more logical ② allow assemblages to be targeted by animation groups 7. GROUPED ANIMATION EFFECTS ============================ Shane’s proposal in brief: 1. Use TimingGroups as compositor groups. 2. parameterize merge. We’ll talk about this at the face-to-face. 8. FACE-TO-FACE DRAFT SCHEDULE ============================== 1. Play Control 2. Timing (sharing, templating, separate object etc.) 3. Effect templating 4. Groups 5. Media Integration 6. Autoplay behaviour 7. Spec finalization and cleanup - motion path - CSS integration - color interpolation - ... Next meeting: Sydney F2F, 11 - 15 Feb 2013 @ Google in Sydney Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Wednesday, 23 January 2013 02:13:11 UTC