- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 17 May 2013 13:32:55 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 16 / 17 May 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.eUtb$hsAAim/latest Present: Doug, Shane, Steve, Brian Agenda: 1. Status update 2. F2F dates 3. Fill mode use cases 4. Other feedback 5. Path animation 6. Animatable properties / types 7. Keyframe offsets outside [0, 1] 8. Timing hierarchy manipulation 9. Qualities of target properties 10. Accumulation 11. Timing calculations in the spec 1. STATUS UPDATE ================ Brian: - Removed event propagation - Remove special pause behavior that applied before a player's start time - Reworked interaction with script section - Added TimedItem.parent member (oops!) - Fixed(?) time fraction calculations (thanks Doug and Shane!) - Reworked interaction with page display section - Addressed some review feedback (renaming concepts in animation model) Doug: - Still working on timing calculations. 2. F2F SCHEDULE =============== Web Animations F2F: Mon-Tues 27-28 May, Fri 31 May @ Mozilla Japan Target: request for FPWD on Wed 29 May. 3. FILL MODE USE CASES ====================== Possible example: new Animation(target, { position: 'absolute', left: '0px', top: '0px' }, { position: 'absolute', left: '100px', top: '100px' }, { fillMode: 'none', ... }); But underlying value has position: auto, etc. Basically, anywhere you want to control the movement of something from one predetermined state to another, but don't want the Animation to control the position after that point. This is a common effect where you want the animation simply to be a cosmetic overlay for an underlying change in state. However, we're specifically looking for cases of fill: none inside fill: forward. > We don't really have any concrete examples of use cases where parent is fill: forward and child is fill: none but we suspect that in this case it is more intuitive for the child's fill: none to be respected. Experience in the polyfill also suggests this behavior is less likely to produce inconsistencies at interval boundaries due to floating-point inaccuracy. > Brian to spec out fill: none on descendant always being respected. 4. OTHER FEEDBACK ================= We (Google Sydney) have a doc with other feedback (https://docs.google.com/document/d/1bOsBLoyZ_toIOiU_uIbepXPRzoKkUKmcN0tR4HcHYOw/edit). We've already added information about some of the larger threads from our review. Here's some more minor ones: 1) The specification is currently written in a way that implies lots of things are not animatable. We think it's better to allow everything to be animatable and define default animations that are step animations. This allows for some interesting tricks like setting position: absolute for the duration of an animation. > Discussion moved to section 9. 2) Accumulation doesn't seem to be quite right at the moment. For example, imagine animating to 50px with an underlying value of 100px. Some valid accumulation behaviours could be: a) keep animating linearly (i.e. 100px -> 50px in the first iteration, 50px -> 0px in the second) b) 're-apply' animate-to (i.e. 100px -> 50px in the first iteration, 50px -> 50px in the second) What is currently specced will do 100px -> 50px in the first iteration, 150px -> 50px in the second. > We will try to spec (b) for now, that is, use the final value of the previous iteration as the underlying value. We hope this can be implemented without having to actually calculate the final value of every iteration. 5. PATH ANIMATIONS ================= We have a draft spec: https://docs.google.com/document/d/1D40pVzgWeYCivDxG6FFKgiZW7p4CuE_395iT8sTMklo/edit We decided to try doing this section entirely by-reference to SVG Paths. Is this OK or should we try something different? > Answer: Not ok; it would make SMIL a normative reference. 6. ANIMATABLE PROPERTIES / ANIMATION OF PROPERTY TYPES ====================================================== We have started writing this section. It's in the same doc as path animations. I'd really like to know whether this is going in the right direction or not. > Discussed under section 9. 7. KEYFRAME OFFSETS OUTSIDE [0,1] ================================= Revisiting this from last time. Any thoughts? Brian to follow up next week with Mozilla. Shane to try and get some comments from Tab. 8. TIMING HIERARCHY MANIPULATION ================================ (Brian) There are two issues here: A) Removing a node is *really* hard, i.e. anim.parent.remove(anim.parent.indexOf(anim)); I think that deserves a medal for worst API ever. So, I thought, why not add a version of remove() that takes a TimedItem giving you: anim.parent.remove(anim); Which looks a lot like how people use the DOM but that lead me to (B) B) Recent additions to DOM (DOM4/dom.spec.whatwg.org) changes the way this stuff works Now we have, node.removeChild() - Removes the child (marked as 'legacy') elem.remove() - Removes the element from the parent (new) Likewise, elemA.replace(elemB) - Replaces elemA with elemB amongst elemA.parentNode's list of children elemA.after(elemB) - Inserts elemB into elemA.parentNode's list of children after elemA elemA.append("hello") - Appends the text node "hello" as the last child of elemA's list of children I think we ought to align with this. That might mean: * Renaming TimedGroup.remove to removeChildren, and/or * Making TimedItem.remove remove from the parent (It might make sense to have Player.remove() detach from the timeline) * Replacing TimingGroup.add with append/prepend * Consider removing splice Shane: YES. The new API is so much nicer. > Brian to have a go at reworking TimingGroup to line up with new DOM methods Also discussed splice, will leave out for now, easy to add later. One use case to bear in mind is the following: I have a sequence group used to do a kind of frame-based animation where each child animation shows an image for a short-time. I want to extend the sequence by adding 100 more frames. Calling 'append' 100 times is going to be slow. One work-around for the time being would be to construct a new sequence group (the constructor for a sequence group takes an array of timed items) and append the new sequence group to the existing one. It's a bit messy but we can easily add splice later if needed. It's much harder to remove it. 9. QUALITIES OF TARGET PROPERTIES ================================= There seem to be a few different ways of seeing things: A ("The CSS/SVG way" ?): - Some properties are animatable, some are not - Some types are interpolable, some are not - Some types are additive, some are not More specifically: - Some properties are animatable, some are not - CSS: if it's not marked as animatable, or it is "Animatable: no" then it's not animatable - SVG: some are marked explicitly as not animatable e.g. direction, enable-background, glyph-orientation-horizontal, glyph-orientation-vertical, unicode-bidi, writing-mode - Some types are interpolable, some are not - CSS: some combinations of values are interpolable, some are not - SVG: "The default mode is 'linear', however if the attribute does not support linear interpolation (e.g. for strings), the ‘calcMode’ attribute is ignored and discrete interpolation is used." - basically SVG says everything is interpolable (but don't necessary support linear interpolation) - Some types are additive, some are not - CSS: n/a - SVG: Some *types* are additive, some are not (e.g. frequency, time) B ("The mathematical way" ?): - Everything is animatable, except the things that aren't - Everything is interpolable, but sometimes only discrete interpolation is available - Everything is additive, but sometimes addition just returns the RHS Discussed approach B. The first, part is probably fine, i.e. > "Everything is animatable unless otherwise stated" > Brian to rework existing stuff about properties to make it say things are animatable by default The others may be ok to, but we'd like to see how they shape up when spec'ed out. We'd like to provide the necessary hooks/definitions so future specs can say, for example, "this property is able to be linearly interpolated but attempting to add it simply returns the value being added" or something of that sort. > Google Sydney team to rework draft animatable properties section in light of this 10. TIMING CALCULATIONS IN THE SPEC =================================== Deferred a number of issues until F2F / IRC but briefly discussed the following: * Shane + Steve thought currentIteration should be null outside the active interval (even when filling) Current iteration could include the time fraction? Might be better called "progress". i.e. progress (double): <current-iteration>.<time-fraction> The difficulty with this is it doesn't accommodate the situation where you are applying the final value (e.g. fill: forwards). It might not be so difficult to detect those situations though in the animation model and handle accordingly. Needs further investigation. Next meeting: Mon May 27 9:00 JST @ https://etherpad.mozilla.org/T1VWmY82NH / Mozilla Japan Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 17 May 2013 04:33:30 UTC