Re: Web Animations, minutes 14 / 15 August 2012

I was also supposed to summarize the group templates idea before Brian sent
out the minutes, but I didn't get to it until late last night. Here's the
summary I wrote up (warning: this is looooong)

Cheers,
    -Shane

----

I introduced the idea of a "resolution strategy" that could apply to
templates and group templates.

Normally what happens for an animation template is that an animation
instance is generated for each element in the list provided to the animate
method. Similarly, for an animation group template, an animation group
instance is generated for each element in the list, and each element in the
list is provided as a singleton list to each child of the group; with the
resulting animation instances appended to the relevant animation group
instance.

That's complicated for groups :) Basically it means that:

AnimationGroupTemplate([AnimationTemplate1,
AnimationTemplate2]).animate([e1, e2])

results in 2 AnimationGroups, each with 2 Animations as children (one
derived from AnimationTemplate1 and one derived from AnimationTemplate2 for
each AnimationGroup). Both children of the first animation group target e1,
and both children of the second target e2.

What a resolution strategy does is provide a way of processing the element
list that is provided to a template before creating instances of
animations.

I supplied 2 examples, with the caveat that the syntax is far from final :)

1)
a "selector" resolution strategy takes each element in the element list and
finds a child of that element that matches the provided selector.

var up = new Anim(keyframesFor("top", 200, 0), new Timing(0, 1000),
"selector: .top");
var right = new Anim(keyframesFor("left", 0, 200), new Timing(500, 1000),
"selector: .right");
var down = new Anim(keyframesFor("top", 0, 200), new Timing(1000, 1000),
"selector: .down");

var group = new AnimGroup("par", new Timing());
group.append(up);
group.append(right);
group.append(down);

group.animate(document.querySelector(".group"), 0);

This is designed to apply to a fragment of DOM such as:

<div class="group">
        <div class="top"></div>
        <div class="right"></div>
        <div class="down"></div>
</div>

This is a way of matching complex animations to complex patterns in the DOM.

2)
a "target" resolution strategy replaces the element list with a new list
based on the ids provided in the strategy.

group.animate(document.querySelector(".group"), 0);

var group = new AnimGroup("seq", new Timing());
group.append(new Anim(keyframesFor("left", 100, 150), new Timing(0, 1000),
"target: a"));
group.append(new Anim(keyframesFor("left", 100, 150), new Timing(0, 1000),
"target: b"));
group.append(new Anim(keyframesFor("left", 100, 150), new Timing(0, 1000),
"target: c"));

group.animate([], 0);

This is designed to apply to a fragment of DOM such as:

<div>
        <div id="a" class="anim"></div>
        <div id="b" class="anim"></div>
</div>
<div>
        <div id="c" class="anim"></div>
</div>

(note that the animated divs are not all in the same subtree). This is a
way of playing complex animations attached to named elements in the DOM
multiple times in the timeline.

Of course the two strategies can be mixed and matched, and we can think of
others too. One example of mixing the strategies is an animation for
deleting files - the file flying into a trash can animation needs to be
applied to a different element each time a file is deleted, but the trash
can gobbling up the file applies to the same element each time. So the file
has a selector strategy applied to it while the trash can has a target
strategy applied.

Note that one consequence of this approach is that if you do something like:

var group = new AnimGroup("seq", new Timing());
group.append(new Anim(..., "selector: .foo"));

and apply it to something like:

<div>
  <div class="foo"></div>
  <div class="foo"></div>
</div>

Then _both_ divs will generate anim instances in the anim group instance,
so they will play sequentially.

Furthermore, if you do something like:

var group = new AnimGroup("par", new Timing());
group.append(new AnimGroup("seq", ..., "selector: .foo"));
group.children[0].append(new Anim(..., "selector: .bar"));

and apply it to something like:

<div>
  <div class="foo">
      <div class="bar"></div>
      <div class="bar"></div>
  </div>
  <div class="foo"></div>
      <div class="bar"></div>
      <div class="bar"></div>
  </div>
</div>

Then you'll get an anim instance like:

<par>
  <seq>
    <anim> // on first bar
    <anim> // on second bar
  </seq>
  <seq>
    <anim> // on third bar
    <anim> // on fourth bar
  </seq>
</par>

I think this is actually correct, but it could be a bit confusing at first.



On Wed, Aug 15, 2012 at 5:53 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Web Animations, minutes 14 / 15 August 2012
>
> Etherpad: https://etherpad.mozilla.org/**IW8zT9yCin<https://etherpad.mozilla.org/IW8zT9yCin>
> Present: Dmitry Baranovskiy, Alex Danilo, Shane Stephens, Brian Birtles
>
> Agenda:
> 1. Status update
> 2. Tidying up the Timing/TimedItem interface
> 3. Pause behaviour
> 4. Suggestions from public-fx, www-style
> 5. Group templates
> 6. More thoughts on templates
> 7. Constructors for Anim etc.
>
> 1. STATUS UPDATE
> ================
>
> Dmitry:
>  - Sequence group and delay diagram
> Brian
>  - Template / liveness changes
>  - Ctors for Anim etc.
> Shane
>  - Emulator work, playing around with "resolutionStrategy" for group
> templates
>
> 2. TIDYING UP THE Timing/TimedItem INTERFACE
> ==============================**==============
>
> I (Brian) think some renaming might be in order.
>
> In general:
>
> duration -> dur
> animation -> anim
> function -> func
>
> e.g. AnimFunction -> AnimFunc
> iterationDuration -> iterationDur
>
> Shane, Alex: Ok
> Dmitry: I don't care
>
> Also to align with HTMLMediaElement::
>
> speed -> playbackRate
>
> Shane, Alex: Ok
> Dmitry: I'm fine [with that]
>
> Current pause methods:
> pause()
> unpause()
> getPauseState()
> isPaused()
>
> Replace with:
>   attribute boolean pauseState;
>   readonly attribute boolean paused; // takes into account parents' pause
> state
>   pause(); // Sets pauseState to true -- for compatibility with
> HTMLMediaElement
>
> Shane: what about localPauseState? Need to differentiate more between
> paused and pauseState.
> Brian: too long!
> Alex: OK, makes sense
>
> pause() ► play()?
>
> What about play()?
>   In HTMLMediaElement, play() unpauses if paused. If it has finished, it
> also does a seek, but if it's playing it does nothing... I think
>   http://dev.w3.org/html5/spec/**media-elements.html#dom-media-**play<http://dev.w3.org/html5/spec/media-elements.html#dom-media-play>
>
> Shane: Can we do something like play(boolean seekToStartIfFinished=true)?
> Dmitry: No way! No boolean attributes please.
> Brian: Let's make play always seek if finished (like HTMLMediaElement) and
> if you don't want that then just change localPauseState.
>
> Alternatives to localPauseState:
>
> Brian: itemPaused, localPause ?!
> Shane, Alex: locallyPaused
>
> > Go with locallyPaused for now and add an issue
>
> Another alternative
>
>    attribute boolean paused;
>    readonly attribute boolean effectivelyPaused; ?? notMoving??
> asGoodAsPaused ?? aintGonnaPlay ??
>
> Ok, maybe not.
>
> Rename:
>   iterationDuration -> duration // matches HTMLMediaElement / CSS / SVG
> Shane: NOOOOOO
>   iterationTime -> currentTime // matches HTMLMediaElement
> Shane: NOOOOOO
>       // currentTime is writeable in HTMLMediaElement ... make it
> writeable??
>   itemTime -> ??
>   itemDuration -> ??
>
> Crazy idea:
>   -- consistently named, match core concepts
>   iterationDuration / iterationTime
>   itemDuration / itemTime
>   animDuration / animTime (maybe don't worry about these)
>
>   -- aliases for "consistency"
>   currentTime (=iterationTime)
>   duration (=iterationDuration)
>
> Other options
>
>   time.iteration
>   time.anim
>   time.item
>   dur.iteration
>   dur.anim
>   dur.item
>
> Or
>
>   timing.iteration.time
>   timing.iteration.dur
>   timing.iteration.index
>   timing.anim.time
>   timing.anim.dur
>   timing.item.time
>   timing.item.dur
>
> Dmitry, Shane, Alex: we like this a lot
>
> Need to rename timing to something else though since we already have a
> timing property.
>
> Dmitry: s/timing/realtime/ s/timing/current/?
> s/timing/now/ ?
> s/timing/**officiallyDesignedByCommittee_**TM_/
>
> > Brian to decide
>
> 3. 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%?
>
> > Answer is: 10%, i.e. pausing, in effect, remembers the item time, not
> the animation time.
>
> Shane: In future, we can provide a version that remembers the animation
> time
>
> 4. SUGGESTIONS FROM public-fx, www-style
> ==============================**==========
>
> * François REMY in particular has been very helpful in discussing
> integration with media.
> (See thread starting here: http://lists.w3.org/Archives/**
> Public/public-fx/2012JulSep/**0006.html<http://lists.w3.org/Archives/Public/public-fx/2012JulSep/0006.html>)
> Some suggestions:
>  - Liveness  proposal A from last time
> > Already adopted
>
>  - Factor out a common TimeSource interface that MediaElements could
> implement as well as TimedItem. I haven't really looked into it too much.
> > Needs more thought
>
>   - Renaming some of our properties to line up with MediaElements would
> help here (e.g. speed -> playbackRate)
> > Already agreed to this
>
> - Also possibly reworking timelineStart to follow the autoplay mechanism
> > Needs more thought.
>
> - Rather than making the effects timeline not seekable, make it a property
> of all groups that they can be seekable / not-seekable.
> Shane: thinks this is worse for web devs (harder to reason about) and
> worse for implementors (harder to optimise)
>
>   - I would prefer if the “animate” and “animateLive” functions were
> called “createInstance(s)” and “createLinkedInstance(s)”
> > No longer relevant in light of changes made to templates / liveness
>
> - Rename “animate*WithParent(el,group)” in to
> “create*Instance(s)InGroup(el,**group)”
> > No longer relevant once we redo AnimGroupTemplate?
>
> - There are some comments about sorting within the global animation stack
> that I (Brian) 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
> See thread: http://lists.w3.org/Archives/**Public/www-style/2012Jul/0703.*
> *html <http://lists.w3.org/Archives/Public/www-style/2012Jul/0703.html>
> and http://lists.w3.org/Archives/**Public/www-style/2012Aug/0079.**html<http://lists.w3.org/Archives/Public/www-style/2012Aug/0079.html>
>
> e.g.
> 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?
>
> e.g.
>
> <par>
>    <div class="welcome">
> </par>
>
> 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>
> </video>
>
> > General sentiment that this looks interesting
>
> *   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.
>
> AI: Shane will look into whether this is currently the "more natural"
> result anyway.
>
> 5. GROUP TEMPLATES
> ==================
>
> Shane showed some good ideas about how group templates might make use of a
> selection strategy for items to target different children of the group.
>
> Below, is just some thinking out-loud about how it might map to SVG.
>
> <svg>
>  <g>
>   <g class="foo">
>    <rect/>
>    <rect/>
>   <g>
>    <circle/>
>   </g>
>   <g>
>    <circle/>
>   </g>
>  </g>
>  <defs>
>  <par select=".foo" id="complex-anim">
>    <animate select="rect:nth-child(2)" ... />
>    <par select="g">
>     <animate select="circle" ... />
>     <animate ... />
>    </par>
>   </par>
>  </defs>
> </svg>
>
> Some discussion about what the default scoping was for <par select=".foo">
> and it seems to be agreed it would be that of the parent element.
>
> AI: Shane to specify this and add as an issue Brian's suggestion of
> attaching the resolutionStrategy to the group rather than the element.
>
> 6. MORE THOUGHTS ON TEMPLATES
> =============================
>
> interface Anim {
>     readonly attribute Timing timing;
>     attribute AnimFunc animFunc;
> }
>
> Thinking of making timing writeable. Should it also be shareable? We *can*
> define it so that setting it automatically makes a copy. SVG does that a
> lot so it's not unusual. Or we can make it shareable.
>
> Likewise for AnimFunc. One difference here is that if we allow AnimFunc to
> potentially be user-defined, we are kind of forced into allowing sharing??
>
> Update: I've (Brian) made Anim.func writeable and shareable as well as
> Anim.template. I'll make Anim.timing writeable and shareable soon too I
> expect.
>
> 7. CONSTRUCTORS ON Anim etc.
> ============================
>
> See changes to spec.
>
> Currently looking at an interface like so:
>
>   var anim = new Anim(elem, { dur: 3, height: '100px' })
>
> Shane:
>   //also allow
>   var anim = new Anim(elem, new Timing(...));
>
> Brian: We already support,
>   var anim = new Anim(elem, { timing: new Timing(...), animFunc: new
> KeyframesAnimFunc(...) } )
>   var anim = new Anim(elem, { dur: 3, animFunc: new KeyframesAnimFunc(...)
> })
>                  = new Anim(elem, { dur: 3, height: '100px', width:
> '200px' })
>
> Shane: used to have it that:
>   animate - bag o' properties
>   constructor - pre-built objects
> This isn't more complicated
>
> Sent mail to public-script-coord about supporting this:
> http://lists.w3.org/Archives/**Public/public-script-coord/**
> 2012JulSep/0100.html<http://lists.w3.org/Archives/Public/public-script-coord/2012JulSep/0100.html>
>
> > Need to revisit this next time
>
> Next meeting: 21 Aug 18:20 PDT / 22 Aug 11:20 AEST / 22 Aug 10:20 JST @
> https://etherpad.mozilla.org/**IFCnsPoRSr<https://etherpad.mozilla.org/IFCnsPoRSr>
>
>