Server Notice:


Public Pad Latest text of pad CVoYIc2pWz Saved Aug 10, 2012

Meeting 26
9 Aug 18:00 PDT / 10 Aug 11:00 AEST / 10 Aug 10:00 JST
1. Template classes
2. Removing the Timing interface
3. Seek revisited
4. Liveness
5. Tidying up the Timing/TimedItem interface
6. Pause behaviour
7. Suggestions from public-fx, www-style
0. Status updates
Brian: added timing model intro and got rid of active state section
Shane: excited about the no-template approach
Any news?
1. Template classes
> After much (fruitful) discussion, we're inclined to keep templates in some form. We would make them optional. Much of the difficulty surrounds group templates and allowing children to target different elements. We are thinking of adding functionality to AnimGroupTemplate to allow this target element selection strategy to be defined there. Under that scheme templates diverge from instances further which supports the idea of templates being optional--they are utility objects for advanced users and CSS/SVG rather than being fundamental to the model.
> Shane is going to prototype some ideas on how to decide on element references when (1) instantiating an AnimGroupTemplate hierarchy and (2) modifying an AnimGroupTemplate hierarchy with existing instances for next Wednesday (/ Tuesday)
> We also agree with the approach put forward by François of throwing exceptions when attempting to modify a linked instance, and requiring an explicit call to unlink in order to modify the instance.
> With regards to making templates optional, an Anim that is created directly would still have a template property but it would be null. An Anim created from an AnimTemplate would have a template property that points back to the template.
We will add convenience methods / constructors for cloning existing animations and possibly producing templates from them so that new animations could share information with existing ones.
Much of the difficulty with filling in the template property always is when it comes with groups.
Discussion of possible convenience methods:
e.g. one possible convenience method
? animA.template // null
animB = animateAndTieTogether(animA)
animB.template === animA.template !== null
// i.e. animateAndTieTogether is a convenience method to create the template and tie two together
This option was not so popular
e.g. 2, two methods
? animA.template // null
template <- animA.templatize()
? animA.template !== null
animB = animateLinked(animA.template)
animB.template === animA.template !== null
This option is more popular
This would probably only work for animations and not groups
So, should unlink set the template property to null?
Yes. <dmitry> and also return the template from unlink().
2. Removing the Timing interface
See notes from last time:
Brian: I spoke with roc and Cameron McCormack (editor of WebIDL) about using methods in place of attributes for some of the calculated attributes. They thought it was not a good idea.
   roc pointed to the precedent of HTMLMediaElement.currentTime (which, by the way, is also set-able). He thinks attributes should be fine so long as reading the attribute doesn't have side effects.
   Cameron suggested that JS coders have not had accessor properties long enough to get a feel for how sophisticated they can be.
   Dmitry: I am strongly disagree on arguments. Actually I don’t see any arguments. :)
Regarding folding the Timing interface into TimedItem and TimedTemplate, we're basically making a trade-off:
a) Defining stuff twice (although we'd just use a property-by-property cross-reference) and blurring the line between specified inputs to the model and calculated outputs (some of which are overrideable), OR
b) Having 1 additional interface (and the additional flicking backwards and forwards that introduces), and the confusion of remembering, "does this property hang off the TimedItem or the timing property?"
Brian: Another thought occurred to me, although I prefer (a) above, we could go with (b) and rename Timing to TimingFunc. Rename the existing TimingFunction to ScalingFunc. Then a simplified view of the animation looks like:
interface Anim {
    TimingFunc timingFunc;
    AnimFunc animFunc;
Since we've decided that seek works on item time, we basically re-inforce that everything inside TimingFunc is inside that item time (i.e. weaken even drop the idea of animation time). TimingFunc acts as a black box in a sense, so of course includes the start delay (since that's part of the timingFunc).
In a sense, timingFunc is the timing model (obviously there's actually a lot more to the timing model than that) and animFunc is the animation model (again, not really true).
> Problem is animation-timing-function in CSS Animations refers to just the scaling function. We might cause confusion if we use "TimingFunc" to refer to something that includes the delay etc.
> Decided to keep the Timing interface. Not sure about renaming.
> Shane to mail to fx group about renaming Timing to TimingFunc
3. Seek revisited
In light of the HTMLMediaElement.currentTime precedent I'd (Brian) like to get rid of seek and just make animationTime writeable.
BUT animationTime is different to item time in two ways:
a) It is the time AFTER adding the startDelay.
b) It is clamped to [0, animationDuration].
So, maybe it makes sense to expose itemTime instead since it isn't clamped (e.g. you can set it to something negative). It also matches what we agreed was the "correct" input to seek().
Dmitry: Could we make animationTime negative? 
Brian: We could. It would mean re-defining a lot of things, but I think we want to use the item time anyway.
Shane: With the caveat that we must expose itemTime I'm happy with this.
Brian: I don't understand. Do you mean that we have to expose this regardless?
* We have animationDuration which doesn't include the startDelay. i.e. if you want to see if an animation has finished, you need to check itemTime + startDelay >= animationDuration. Is that ok?
Shane: itemDuration? (= animationDuration + startDelay)
* itemTime is yet another term to deal with. Can we call it currentTime?
Shane: Uh, no, because that would be confusing in light of HTMLMediaElement.currentTime :)
Brian: And, HTMLMediaElement.currentTime is iterationTime right? Fair enough. That's a shame.
4. Liveness
See notes from last time:
Are we now in a position to decide between?
uno) Option A [allow linked instances, throw exception on attempt to change]
due) Option C followed by A (or similar) in the future [no liveness at first]
5. Tidying up the Timing/TimedItem interface
Whether we merge these interface or not, it seems like some renaming is in order
We have:
interface Timing {
    attribute float               startDelay;
    attribute unrestricted float? iterationDuration;
    attribute unrestricted float  iterationCount;
    attribute float               iterationStart;
    attribute float               speed;
    attribute PlaybackDirection   direction;
    attribute TimingFunction      timingFunction;
    attribute FillMode            fill;
    Timing clone ();
interface TimedItem {
    readonly attribute Timing             timing;
    readonly attribute float?             animationTime;
             attribute unrestricted float animationDuration;
    readonly attribute float?             iterationTime;
    readonly attribute unrestricted float iterationDuration;
    readonly attribute unsigned long?     currentIteration;
             attribute float              startTime;
    readonly attribute unrestricted float endTime;
    readonly attribute AnimGroupInstance  parentGroup;
    readonly attribute float              timeDrift;
    void start (optional float timeFromNow = 0);
    void stop (optional float timeFromNow = 0);
    void pause ();
    void unpause ();
    bool getPauseState ();
    bool isPaused ();
    void seek (unsigned long itemTime);
    void changeSpeed (float speed);
    void reverse ();
    void cancel ();
Note that one of the key concepts is:
* iteration time and iteration duration -- the time within/for one iteration
* animation time and animation duration -- the time within/for the whole interval including (potentially) many iterations
Do you find this naming confusing?
Shane: Nope.
Some suggestions:
animationTime -> currentTime
animationDuration -> repeatedDuration
iterationDuration -> duration (matches CSS and SVG, but could be confusing?)
What do you think?
Shane: I  think these are worse. repeatedDuration (as compared to duration)  doesn't convey the sense of "overall" or "the sum of the intervals" in  the same way as animationDuration (as compared to iterationDuration)  does.
Also, how about the following:
iterationStart -> iterStart
iterationCount -> iterCount (repeatCount?)
iterationTime -> iterTime
currentIteration -> currentIter
duration -> dur
repeatedDuration -> repeatDur
timingFunction -> timingFunc
Shane: NOOOO! "iter" can validly be "iterator", whereas "iteration" is unambiguous.
Shane: "dur" and "timingFunc" are OK.
What about animationTime -> animTime?
Likewise animationDuration -> animDur?
Any thoughts?
6. Pause behaviour
If you pause an animation 25% of the way through, then extend the  startDelay, do you expect the paused animation to jump to, e.g. 10% of  the way through? Or stay fixed at 25%?
7. Suggestions from public-fx, www-style
* François REMY in particular has been very helpful in discussing integration with media.
Some suggestions:
   - Liveness  proposal A from last time
   - Factor out a common TimeSource interface that MediaElements could  implement as well as TimedItem. I haven't really looked into it too  much.
     - Renaming some of our properties to line up with MediaElements would help here (e.g. speed -> playbackRate)
     - Also possibly reworking timelineStart to follow the autoplay mechanism
   - Rather than making the effects timeline not seekable, make it a  property of all groups that they can be seekable / not-seekable.
  - I would prefer if the “animate” and “animateLive” functions were called “createInstance(s)” and “createLinkedInstance(s)”
  - Rename “animate*WithParent(el,group)” in to “create*Instance(s)InGroup(el,group)”
   - There are some comments about sorting within the global animation stack that I suggested Shane could follow up on
*  Julien Dorra has proposed a :time pseudo class originally for lining  things up with media items but is probably more generally applicable
div.welcome:time(3000) {
   display: none;
(Probably want to use seconds instead of milliseconds however)
I  suggest the time could be interpreted based on the time space of the  target element. e.g. if the div was a child of a <par> group the  3000 would be taken as being in the time space of the <par> group.
That would be one avenue for putting CSS animations inside time containers?
   <div class="welcome">
div.welcome:time(3) {
    animation: ...
Not sure how that works for <seq> containers however where the start time is ignored.
If  you define <video> etc. as establishing their own time space  (i.e. make them "animation groups", so to speak) then you can sync with  video.
You can also do this:
<video id="video"> 
  <animate begin="3s" dur="2s" attributeName="filter" ...></animate> 
*  There was also a suggestions somewhere about making the result of  animate(document.querySelectorAll(".zombie")) live--i.e. as new elements  get added with that class, spawning animations to them.
Some of the larger pieces still left before September
* Incorporate changes from today's meeting (Brian)
   -- renaming, removing liveness? removing item time?
* Write up effects vs animation timelines (Brian)
* Write up global Animate / Animate.effect functions (Brian)
* Add duration: time | auto | % (Brian)
* Pseudo element superclass (Brian)
* Add TimedItem.resetDrift(optional deep = false) (Brian)
* Add description of timing model (Brian)
* Lots of other renaming etc. (Brian)
* TimingFunction interface
* Constructors, especially for groups (Brian)
* AnimFunction.pace -- drop this for now?
* Script-based AnimFunctions
* Various TODOs under 10. Primitive animation operations
* MediaGroup intergration
* Events
* SVGOpen presentation / demo