Server Notice:


Public Pad Latest text of pad 6dtzemgWAe Saved Jan 8, 2013

Meeting 38:
Web animations minutes, 7 / 8 January 2013
1. Status update
2. FPWD criteria
3. F2F planning
4. Timing interface / defaults
5. Scope of time sources
* 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
- Resolve Timing interface / defaults interface approach
- Resolve autoplay behaviour of newly created animations
- Element interface extensions
- Media integration outline (for patent reasons)
- SmoothTimingFunction outline (for patent reasons)
- PathAnimationEffect outline (for patent reasons)
  - 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.
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
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
endTime - default?
activeDuration - run-time
One alternative composition if we were to expose all this (nobody particularly likes this except brian who doesn't love it):
endTime + defaultEndTime
activeDuration + defaultActiveDuration
Sydney team to prepare comparison document.
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
Five ways which templates are used:
1. Mapping CSS markup to API objects
We can't use the previously defined templating behaviour for all of this.
2. As an API to manipulate CSS markup
Not really using the templating mechanism, but 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
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)