Web Animations minutes, 9 / 10 August 2012

Web Animations minutes, 9 / 10 August 2012

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.FxQ8wHYc9oJ/latest
Present: Dmitry Baranovskiy, Alex Danilo, Shane Stephens, Brian Birtles

Agenda:

1. Template classes
2. Removing the Timing interface
3. Seek revisited

1. TEMPLATE CLASSES
-------------------

See: https://etherpad.mozilla.org/07VpfyGtdw

 > 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: https://etherpad.mozilla.org/bfJdTefySR

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 Anim.seek 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?

Issues:

* 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.


Next meeting: 14 Aug 18:20 PDT / 15 Aug 11:20 AEST / 15 Aug 10:20 JST @ 
https://etherpad.mozilla.org/IW8zT9yCin

Received on Friday, 10 August 2012 04:27:38 UTC