Web Animations minutes, 9 Jan 2014 Present: Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.-ZHzO6BebF-/latest Agenda: 1. Status updates 2. Handling step timing functions at boundaries 3. Start of the document timeline 4. Test suite 5. Accessor for normalized property-specific keyframes 0. Meeting time =========== 11pm CET / 7am JST / 9am AEDST / 3pm PST might be a better time for everyone. Preferably on the same day as SVGWG telcon. Brian to coordinate. Might consider making it 30min later. 1. Status updates ============= Brian: - Replace CustomEffect with callback function - Prototype new player behavior (bounding at only one end) and completely rework player section in spec (added diagrams, replaced 'playing' attribute with 'finished') - Start reworking animation section (making things interpolable by default, splitting out pacing, removing timing function chains etc. etc.) - Other minor edits from last meeting - Looking into start of the document timeline 2. Handling step timing function at boundaries ================================== (Brian) Continuing from last time where we discussed this (http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0233.html, point 4) I went to make the change but noticed that special handling is needed in reverse. For example, consider this case: new Animation(elem, [ { left: '100px' }, { left: '50px' } ], { fill: 'both', direction: 'reverse', easing: 'step-start', duration: 2 }); When we do the forwards fill we will be at active time = 0 since we are going in reverse. The time fraction passed to the timing function will be 0. Normally at t=0 the result is the top of the first step, but in this case we should be filling with the bottom of the step. So we actually have to take care of the *after* phase as well. The same situation occurs when we have a negative playback rate (and we also have to take care of direction: 'alternate-reverse' etc. and check what iteration we're in). I've added wording for this to section 3.12.4 'Timing in discrete steps'. Please check it. 3. Start of the document timeline ========================= (Brian) Currently the spec says the document timeline starts at document load. That was based on the behavior of CSS Animations and SVG. Apparently no-one implements CSS Animations according to that part of the spec and everyone allows animations to start before document load. Also, for SVG2 there has been a request to start animations before load. Proposal: The document timeline starts after current document readiness changes to "interactive" and before dispatching the DOMContentLoaded event. Doug: Why not make it the same as performance.timing.domInteractive from navigation-timing? That is, "the time immediately before the user agent sets the current document readiness to "interactive". Use cases: 1) Animating a spinner while the document is loading (script/CSS) Make it start at time zero and it will begin spinning when the document is interactive. Is that soon enough? 2) Animating a spinner for a really long document so it starts before the document is even fully parsed Stick it in an iframe. Does that work? 3) Make an animation that starts onload from script Set up a load event handler and trigger the animations then 4) SVG backwards compatibility--starting on onload SVG will introduce its own timeline that is a child of the document timeline. By default this will start when the svg document fragment fires its onload event (which I presume is always after the document becomes interactive?) 5) SVG2--starting before onload Provide a "timelineStart" attribute that allows the SVG timeline to be started at the same time as the document timeline. If (1) is too late and (2) isn't a suitable workaround, we could tweak the proposal so that by default the timeline starts when the document readiness changes to interactive, but script can kick-start it before this time (either call start() or set started = true). After further discussion, "interactive" is probably too late for some things like spinners which you want to start as soon as possible. On the other hand, making the zero time "as soon as you get the first byte of data" is too early if animations can be set up to start at time zero since by the time they start running they'll be half-finished. One idea was to make the *document* timeline have its zero time at the earliest possible moment (e.g. first byte of data) but then the SVG timelines (which are nested under the document timeline) will still define their zero time later (e.g. onload event, or when the fragment has been parsed). For CSS, *if* we decide to expose absolute start times then we could define what the zero time is then... or so I (Brian) though until Dirk raised the question of synchronizing SVG and CSS animations. For example, It seems like it would be nice to be able to line these up declaratively. We talked about the general need to be able to synchronize CSS animations independent of SVG. If you have the same animation applied to two different elements then they may start at different times due to when the computed style gets resolved (which could be quite different in a large document). So we considered the idea of exposing very simple timing groups to CSS, e.g. div { animation-group: 'abc'; animation-name: 'bob'; animation-duration: 3s; animation-start: 0s; } li { animation-group: 'abc'; animation-name: 'fred'; animation-duration: 3s; animation-start: 0s; } Not sure if this really works and is scalable. If you later match some elements (After t=3s) they won't play since they are defined to run until t=3s which has already passed. So could you really re-use this for doing dynamic batches of changes? The possibility of having very simple groups to synchronize CSS still seems attractive though since it is a big need. Any suggestions? One further thought, in order to tie SVG and CSS times it might be nice if you could do: Or something like that but that still doesn't really solve the problem for coordinating just CSS animations. Maybe animation-timeline plus a @timeline rule? Needs more thought. One use case to consider is a batch of animations that run every time an event fires. You need a new instance of that timeline (actually group) every time. Needs more thought. > Probably document timeline should have its zero time at say, "domLoading". SVG will provide a different zero time and we will investigate ways to synchronize CSS-with-CSS and CSS-with-SVG. > We should also present this at the FXTF meeting in Seattle in Feb 29. 4. Test suite ========== (Doug) We're interested in building/contributing to a shared test suite for the specification but don't want to begin this work until we're relatively confident that large curn in the spec is behind us. What is still outstanding? If we're aware that certain sections will change significantly we can delay work there. > First step would be to set up repo and agree on templates/structure/format. 5. Accessor for normalized property-specific keyframes ========================================== (Doug) Currently it's not possible to reflect on the normalized keyframes of a KeyframeEffect without reimplementing the algorithms for normalization and distribution. A use case where this came up is a tool which edits and visualizes keyframes. Ideally the tool would be able to output the offsets chosen by distribution: eg. http://web-animations.github.io/web-animations-demos/components/web-animations-tools/wat-keyframe-editor/ Proposal: Expose normalized/distributed keyframes via a separate accessor on KeyframeEffect. This would be a similar pattern to the specified and computed timings exposed from TimedItem. We might also rename getFrames to getSpecifiedFrames. The output of the new accessor could take a few different forms. Some options: Some examples given input of: [ {left: '0px', top: '0px'}, {left: '100px', top: '100px'}, ] 1. Property-indexed: { left: [{left: '0px', offset: 0}, {left: '100px', offset: 1}], top: [{top: '0px', offset: 0}, {top: '100px', offset: 1}] } Pros: - Easy to find all the keyframes for a specific property. 2. Flattened [ {left: '0px', offset: 0}, {top: '0px', offset: 0}, {left: '100px', offset: 1}, {top: '100px', offset: 1} ] 3. { left: [{value: '0px', offset: 0}, {value: '100px', offset: 1}], ... Pros: - Valid as input. - Aligns with the accessor for the specified frames. The reason why we didn't only provide this accessor is that if you supply keyframes without offsets meaning, "Space them out for me", then if you later fetch the keyframes to modify them and set them again, if the keyframes came back with the offsets fill in with their calculated values you would have to manually clear them again before setting in order to get the auto-spacing behaviour. > Probably we will end up adding both methods, but when Brian rewrites the pacing/spacing stuff we will consider if there is a way to, for example, have the computed offsets returned but have a spacing mode of "auto-distribute" (or whatever we call it) override those values.