- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 26 Jul 2013 14:26:51 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 25th / 26th July 2013 Present: Doug, Shane, Brian Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.xVbf92goJvu/latest Agenda: 1. Status updates 2. Phased implementation strategy 3. Revisit per-property keyframe syntax 4. Add 'computed' and 'specified' timing function distinction 5. Roadmap 6. CSS Properties, Animation and Transition insertion points, and pain 7. PFWG review comments 8. Default fill mode 9. Shorthand properties 1. STATUS UPDATES ================= Brian: - Renamed time drift to time lag and exposed to API - Incorporated the new fill mode behaviour (which also meant renaming the 'active' state to 'in play'; introducing phases and a bunch of other edits--please review) - Blog post introducing players: http://brian.sol1.net/svg/2013/07/25/players-wanted-the-pause-and-seek-game/ Doug: - Implemented new fill mode behavior and phases in Blink - Announced intent to implement JavaScript API in Blink: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/KF3Cwr_Kcl0/BSp04-_ERYkJ Shane: - responding to intent to implement thread - thinking about GSAP use cases and responding - thinking about Kevin's mail Polyfill: - Getting closer to automated testing on Firefox. The tests are running, but failures do not gate new changes yet. - Support for CSS keywords - Correct interpolation of background-position - Support for animating CSS shorthand properties 2. PHASED IMPLEMENTATION STRATEGY ================================= We talked about synchronizing the release of parts of the API. Each phase of API implementation could then be followed by feedback gathering, in order to ensure that we end up with the best possible API at the end. One possible phasing breakdown: (1) Element.animate (2) Events + Animation constructor (3) ParGroup / SeqGroup There seems to be support for this idea, so we should probably consider it a bit further then spec something out. 2. REVISIT PER-PROPERTY KEYFRAME SYNTAX ======================================= (Doug) Our experience with making this change in the polyfill wasn't pleasant. Can haz per-property syntax back (in addition) plz? The "chosen" syntax is per-offset: [{offset?: 0.2, composite?: add, (<property>: <value>)*}*] For example: {left: "100px"} [{left: "0px"}, {left: "100px"}] {left: "100px", top: "120px"} [{left: "0px", top: "20px"}, {left: "100px", top: "120px"}] [{left: "0px", top: "20px"}, {top: "120px", offset: 0.7}, {left: "100px"}] [{left: "100px", top: "20px"}, {top: "120px", offset: 0.7}] [{left: "100px", top: "20px"}, {top: "120px", offset: 0.4}, {left: "50px"}, {top: "100px", offset: 0.7}] [{transform: 'translate(100px)', position: 'absolute'}, {transform: 'translate(200px)}, {transform: 'translate(300px)}, {transform: translate(100px), position: 'absolute'}] The "prodigal" syntax is per-property: {<property>:[<value>|{offset?: 0.2, composite?: add, value:<value>}]*} For example: {left: "100px"} {left: ["0px", "100px"]} {left: "100px", top: "120px"} {left: ["0px", "100px"], top: ["20px", "120px"]} {left: ["0px", "100px"], top: ["20px", {offset: 0.7, value: "120px"}]} {left: {offset: 0, value: "100px"}, top: ["20px", {offset: 0.7, value: "120px"}]} {left: ["100px", {offset: 0.55, value: "50px"}], top: ["20px", {offset: 0.4, value: "120px"}, {offset: 0.7, value: "100px"}]} { transform: ['translate(100px)', 'translate(200px)', 'translate(300px)', 'translate(100px)'], position: ['absolute', 'absolute'] } The "chosen" syntax is closer to CSS. The "prodigal" syntax is particularly nice for lists of values for a given property. Would be nice to support both. Question, can we do this without complicating things too much? Related question: Why does getFrames return the partially-normalized keyframes? We could match the specified / calculated pattern we have elsewhere. Discussed possible return values including returning both "specified" and "computed" (i.e. normalized) keyframes. Specified: May not include offsets when auto-distribute behaviour is desired. This is the preferred form if you want to add in extra keyframes and have them be automatically spaced. It is also nice because you can make assumptions about the structure of the data. Computed (normalized): Allows you to inspect how keyframes got distributed and see which properties are supported etc. Observation: Most JS animation APIs don't give you either. Presumably the thought is, "If you need the original object, hold onto it yourself". So if we were to only return one, it should probably be the computed value. The computed/normalized result would follow the per-offset syntax. This will produce more intuitive results for keyframes coming from CSS. For input specified using the per-property notation we would split up the keyframes so there is one keyframe per property value to avoid offset alignment issues. ACTION: Doug to work out what this would look like from an API point of view 3. ADD 'COMPUTED' AND 'SPECIFIED' TIMING FUNCTION DISTINCTION ============================================================= (Shane) This is partly based on the following use case involving paths: Synchronizing with a paced path new ParGroup([ // some complicated animation [red, blue, green] // a path animation [seg1, seg2, seg3] ]) Where do you put the 'paced' timing function? It doesn't work on the ParGroup, but won't apply to the complicated animation if placed on the path animation > This is interesting (not critical, but useful, and with some effort it can be worked around) but we will defer this to the separate spec on timing functions. We should also consider how to set this up declaratively. (In particular, it is currently not too difficult to align animations to occur at certain points along a path animation based on *path length* but not based on *path segment*. That is, if you want to say, "this animation occurs when the paced path animation reaches this *point*", that takes a fair bit of calculation at the moment.) 4. ROADMAP =========== (Brian) Proposed focus for next draft: * Fill modes: inheriting, snapshotting?, overflow? (Inheriting has already been added to the spec) * Timing functions (chaining etc.) * Events * Timeline start * Tighten up animation section * Keyframes outside [0, 1] (Issues in spec, bugs in bugtracker etc.) 5. CSS PROPERTIES, ANIMATION AND TRANSITION INSERTION POINTS, AND PAIN ====================================================================== (Doug) Some important context: (1) the CSSWG has resolved that CSS Animations should apply before !important properties, while CSS Transitions should apply after everything else: UA Properties User Properties Author Properties Inline Styles CSS Animations (Override) Author !important Properties User !important Properties UA !important Properties CSS Transitions (Override !important) Discussion here: http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html > Need to rework spec to bring this in to line with CSS resolutions. The "custom animation priority" hook may no longer be needed. Rather, a separate override stylesheet / stack may be needed. (2) some CSS properties (hereafter called 'priority' properties) impact the computed style of other CSS properties IN THE SAME ELEMENT For example, setting background-color: currentcolor will result in a computed background-color that matches whatever the color: property on the element is. This means that CSS Transitions really do need to be inserted into a different magical style sheet to everything else, otherwise we can't meet the current specification requirements. In particular, take the following case: @keyframes foo { 0% { color: red; background-color: currentcolor; } 100% { color: blue; background-color: currentcolor; } } .foo { transition: background-color 2s; background-color: green; color: orange !important; } .foo.also { animation: foo 2s; } .foo:hover { background-color: currentcolor; } Imagine that you hover over a .foo, then after a second, some script applies the 'also' class. For one second, the transition wins. This means that it finishes transitioning between green and the current color, which is orange. This in turns means that it needs to apply _after_ the orange !important declaration applies. After this point, the transition no longer applies and the animation takes over. However, the animation applies before !important which means background color is transitioning between red and blue. This means that it needs to apply _before_ the orange !important declaration applies. > We should put a note about this into the CSS Integration spec. 6. PFWG REVIEW COMMENTS ======================== http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0008.html > Brian responded. Nothing to add at this point. 7. DEFAULT FILL MODE =================== Recap: Need more input here. Shane preparing draft text used to elicit feedback. Draft text as promised. This may not be concise enough. ------ Fill modes are a feature available in both CSS and SVG animations that allow the first or last value of an animation to apply either before, after, or both before and after the animation itself. We're unable to determine what the default fill mode should be for the Web Animations API, as there are good arguments for making it none, both, or some 'auto' value. On the one hand, the Web Animations API fill mode should default to 'none' to match the defaults of CSS and SVG Animations. This will reduce the number of surprises web authors encounter when refactoring code from CSS or SVG into script using the Web Animations API. On the other hand, our experience is that 'both' tends to be the fill mode used 80% of the time in practice when generating animations using script. Furthermore, when using timing groups[1], we have the following arrangement: child fill mode: 'none', parent fill mode: 'both' -> no fill child fill mode: 'both', parent fill mode: 'none' -> no fill outside the bounds of the parent In order for a child of a group to fill indefinitely in a given direction, both it and all its ancestors need to fill in that direction. On the other hand, in order for a child of a group to not fill, only that child needs to specify a fill mode of 'none'. Switching from 'none' to 'both' requires changing values throughout an animation tree, whereas switching from 'both' to 'none' can be done locally. As a result, we'd like to get your input. Do you think we should: (1) choose a default fill mode of 'none' to match CSS and SVG? (2) choose a default fill mode of 'both' because it makes the API easier to use? (3) add an 'auto' fill mode that defaults to 'none' for animations (matching CSS and SVG) but 'both' for groups (making it easier to switch animations from 'none' to 'both')? > Brian to prepare some diagrams and send. 8. SHORTHAND PROPERTIES ======================== Recap: Need to work out how to prioritize shorthand properties. Should they always come first? Do they belong at all? Can we just assume they are expanded before they reach the model? Brian: I think we can't rule out shorthands from the model because over time longhands often become shorthands. We can't have content break just because it was using something that was a longhand but is now a shorthand. Next meeting: Thurs Aug 25 18:00 PDT / Fri 26 Aug 11:00 AEST / Fri 26 Aug 10:00 JST @ https://etherpad.mozilla.org/PoetD3BlFl Topics for next time: * Making players stop * Independent animation of transform components * Additive/seamless/perfect animations http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0034.html Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 26 July 2013 05:27:21 UTC