W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

[web-anim] Web animations minutes, 7 / 8 January 2013

From: Brian Birtles <bbirtles@mozilla.com>
Date: Tue, 08 Jan 2013 13:34:45 +0900
Message-ID: <50EBA1E5.5040006@mozilla.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2013 04:35:18 GMT