- 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