- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 08 Jan 2013 13:34:45 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web animations minutes, 7 / 8 January 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.9VOScidVy5-/latest Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles Agenda: 1. Status update 2. FPWD criteria 3. F2F planning 4. Timing interface / defaults 5. Scope of time sources 6. Templates 1. STATUS UPDATE ================ Brian: * Split timing model description in separate pieces using partial interfaces * Added diagrams * Renamed animation groups to timing groups * Remove Timing interface * Added defaultPlaybackRate * Made groups use timing windows * Fixed many bugs in pseudocode * Added behaviour for when playbackRate = 0 * Moved templates aside * Added time source interface and description * Added 'filtered time' concept * Renamed animation duration to active duration, likewise animation interval -> active interval * Incorporated reversing of fill mode into handling of playback mode * Renamed item time to local time * Added DocumentTimeSource and revised autostart behavior * Added PseudoElement interface * Added events section Shane, Doug: * hoooolidaaaaaaayyyyys Sydney team: * a lot of thinking about TimeSource / TimedItem 2. FPWD CRITERIA ================ - Resolve Timing interface / defaults interface approach - Resolve autoplay behaviour of newly created animations - Element interface extensions - Media integration outline - SmoothTimingFunction outline - PathAnimationEffect outline - Shane: maybe should have detail of this too? - Introductory prose - Add section on how script updates are handled (outline only is fine) - Primitive animation operations - link to relevant specifications for non-primitive animation operations Good to have a start on CSS (& SVG if possible) integration spec by the time we request approval. 3. SYDNEY F2F PLANNING ====================== SVGWG mon 4th - fri 8th (6th half day) Feb . TtWF fri 8th - sat 9th F2F 11th-15th > Shane to look into office access for Dmitri and Brian during this period > Shane to make sure Alex is available 4. Timing INTERFACE / DEFAULTS ============================== Brian: Reasons to reconsider the Timing interface: * Composition in the interface can be confusing e.g. SVG rect.width.animVal.value - (but CSS is actually moving towards composition): rule.value (string) / rule.rgb.r (red value) * We had TimedItem.duration and TimedItem.timing.duration * We had TimedItem.timing.playbackRate and TimedItem.changePlaybackRate() * HTMLMediaElement uses playbackRate and defaultPlaybackRate *If* we allow both playbackRate and defaultPlaybackRate -> two different end times -> two different active durations Currently: endTime = default end time? activeDuration = playback active duration One alternative composition if we were to expose all this (and nobody particularly likes this except Brian and even he doesn't love it): endTime + defaultEndTime activeDuration + defaultActiveDuration > Sydney team to prepare comparison document of the TimedItem interface with and without a separate timing/defaults object. 5. SCOPE OF TIME SOURCES ======================== (Shane) Previous proposal was that TimedItems have both a time source and a time window This gets really confusing because when Timed Items refer to the document time source they don't get clipped but when you add them to a group and pause them, they get clipped. If we treat pause/play/playbackRate changes of children in animation hierarchies as a rare use case, then we could remove this capability altogether, and instead: * make AnimationGroup <-> Animation a normal parent-child relationship * make Document <-> TimedItem require a TimeSource that associates with the TimedItem * require TimeSource <-> TimedItems to be 1:1 (but TimedItems don't need a TimeSource0 * move play/pause/changePlaybackRate/reverse to the TimeSource interface (Note that this would solve the problem noted under item 4 of having two end times and two active durations for each TimedItem) ISSUE: how do we schedule e.g. multiple videos and animations in sequence, so that pausing one video delays the onset of the next video. > Sydney team to look at this issue and report during next meeting. 6. TEMPLATES ============ (Brian) Five ways which templates are used: 1. Mapping CSS markup to API objects But we can't use the previously defined templating behaviour for all of this. 2. As an API to manipulate CSS markup But not really using the templating mechanism, simply the templating API 3. Mapping SVG markup to API objects There are two different uses: regular <animate> elements (multiple intervals) and <animate> when combined with <use> (multiple targets). Templates *may* work in both situations but it's yet to be proven. 4. As an API to manipulate SVG markup But not really using the templating mechanism, but simply the templating API 5. Purely as an API feature for generating lots of similar animations Brian wonders if we could cover 80%+ of use cases by making clone() more powerful, or allowing Animation.targetElement to target multiple elements (Shane: targetting multiple elements doesn't play well with AnimationGroups). And for the remaining 20%, address it in a future version with something that aligns well with Web Components. Brian agrees that some form of templating is useful. Shane: we think that the best templating approach is to keep defaults objects, and allow them to have: (1) a parent pointer that is optionally null (yes this requires cycle detection but it is simple and cheap) (2) semantics for resolving up the chain Effect templating is done via direct effect sharing. Going back through the five use cases: 1. is no worse. templating behaviour still applies to the second part of mapping CSS to API objects. 2. CSS markup generates defaults and effect objects. 3. is the same, possibly better as there's more flexibility to deal with both types of use 4. see point 2 :) 5. we now have a mechanism for behaviour definition and inheritance that is: - simple - overrideable - not used by default (default initialization uses the TimingDictionary and EffectDictionary) Next meeting: Mon Dec 7, 17:30 PST / Tues 8 Jan 12:30 AEDST / Tues 8 Jan 10:30 JST @ https://etherpad.mozilla.org/WoyQinDYyA Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Tuesday, 8 January 2013 04:35:18 UTC