[web-animations] Web Animations minutes, 15 Apr 2014

Web Animations minutes, 15 Apr 2014

Present: Dirk, Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.5779

Agenda:

1. Renaming
2. Removing time lag
3. Next WD
4. Staged API Release
5. Telcon time
6. Conversion to bikeshed


1. RENAMING
===========
(Brian)

What do you think about renaming TimedItem.specified to TimedItem.timing?

Reasoning:
a) Matches CSS. Specified style is accessed via Element.style. Specified 
timing should be accessed via TimedItem.timing.
b) Matches the interface name, Timing

The only place it gets confusing is 'duration'. Currently we have the 
following:

anim.specified.duration
anim.duration

But with this scheme we'd have:

anim.timing.duration (the specified duration)
anim.duration (the computed duration, read-only)

Doug: I think this is one of the reasons we went with 'specified'. 
Although at the time we were also talking about 'computed' timing and 
whether that should be a separate attribute. eg. anim.computed.duration 
or getComputedTiming(anim).duration
I'm content with 'specified', haven't really seen anyone using the API 
raise this as confusing.

Dirk thinks "specified" is weird. It seems to me that anim.duration 
seems more important than setting the time on the fly. I am in favor for 
anim.duration as read only.

Brian: Option C:

anim.timing.duration
anim.computedDuration

Dirk: No

Shane: Can you clarify - are you in favour of anim.duration being read 
only, or anim.specified.duration?

Dirk: In favor for anim.duration being read only.

Shane: That is OK from my perspective - you can just set 
anim.specified.duration.

Brian: We have one vote for 'timing' (or anything but 'specified') and 
the rest of us don't mind too much.

-> Brian to rename 'specified' to 'timing' and add an issue mentioning 
'specified' as an alternative naming if 'timing' is found to be confusing.


2. REMOVING TIME LAG
====================
(Brian)

We have previously discussed the idea of removing time lag and just 
adjusting the start time as necessary.

Just checking this is really what we want. This means:
- When you are paused, the start time will keep changing. Is that intuitive?
- I wonder if later we'll want to return both the adjusted start time 
and original start time and then we'll be no better off, in fact 
probably worse off since in the end this approach hides more state
- Also, the start time updates while you're paused but not when you 
reach the end (limited)

For now I've checked in a preliminary version: 
https://dvcs.w3.org/hg/FXTF/rev/f7e54dcbd4ea

I'd really appreciate your review. Some of the algorithms are almost 
certainly wrong. If you think this approach is still preferable then I'd 
appreciate you trying it out and filing bugs. Otherwise, if you think 
this maybe isn't the best way let me know soon while it's still easy to 
back out.

See section 3.5, Players

Shane: We'll go over it

Doug: We could remove the start time attribute too. If we need the 
ability to set start time from script, it could be another argument to 
timeline.play. Changing start time could be achieved by 
timeline.play(oldPlayer.source, newStartTime);

Brian: I think it's useful to be able to set the start time after 
creating the player since this is one way of influencing sort order.

Dirk: Isn't it confusing if the startTime can be set by the author but 
pausing will set the start time as well? What happens if you pause and 
then ask for the start time? Will it update continuously while updating?

Brian: Yes

Dirk: Hm. Sounds confusing to me.

-> Dirk, Doug, Shane to read 3.5 in the new approach and evaluate 
whether it's the right approach or not.


3. NEXT WD
==========

Remaining items
(from https://web-animations.etherpad.mozilla.org/todo)

* Removing time lag
   Checked-in preliminary version 
https://dvcs.w3.org/hg/FXTF/rev/f7e54dcbd4ea
   (Needs review *badly*)
-> Waiting on review from Dirk, Doug, and Shane

* Iteration composite mode
  -- Shane and Brian still trying to figure out how this should work
  (Previous discussion here: https://etherpad.mozilla.org/Mb8u9QyS9w )
Shane: I think Brian is right - post-application of the underlying value 
gives best results despite being a little counter-intuitive.
-> Shane to talk this over with other people in Sydney then draft 
Brian's approach into the edit.

* Custom effect calling requirements and an issue about zero-length 
custom effects and the Trigger timed item
Doug: Text is here: 
https://docs.google.com/document/d/14JXp8KXOexVC7t5ogVOQBvhZBH3cK4YRiuV1sxteBk4/edit?usp=sharing
-> Brian to merge

* The above-mentioned renaming if we do it
-> Brian to do


4. STAGED API RELEASE
=====================
(Shane)

For our Blink implementation we intend to send an "intent to ship" for a 
subset of Feature Set A in the next few days.

Motivations:
* Solicit wider feedback. Previous attempts at feedback have generated 
only limited comments.
* Progress towards CR. Web Animations has been an ED for over 2 years, 
and a WD for 10 months. We feel that some implementation pressure will 
help move the specification towards a CR.
* Solidification of implementation experience. While we have gained 
insight into the API through implementation, having a library executed 
by millions of users will significantly improve our understanding of 
performance trade-offs and use cases.

Scope:
* We are proposing that we ship element.animate(...), which returns an 
AnimationPlayer with 'cancel()' and 'onfinish'.
* We will not be shipping an Animation constructor at this time, nor 
will we ship CustomEffects or MotionPathEffects.
* We will mark AnimationPlayer as NoInterfaceObject for now.
* The API names that will be exposed are:
     - element.animate(sequence<Keyframe> effect, optional (double or 
TimingInput) timing)
     - (AnimationPlayer).cancel, .onfinish
     - (TimingDictionary).delay, .endDelay, .fill, .iterationStart, 
.iterations, .duration, .playbackRate, .direction, .easing
     - (Keyframe).offset, .easing

Risks:
* Part of the proposed release may change. We are prepared to deprecate 
and make breaking changes to Blink if necessary to stay in 
synchronization with the specification. It may not be practical to 
re-use names of features that become widely used.

Brian: Why this subset?

Shane: Corresponds (roughly) to what you can do with CSS currently

Brian: Are composite modes included?

Shane: No

Brian: Interaction with CSS animations / transitions / API-generated 
specified anywhere?

Shane: Not yet. We have discussed this in the past but nothing has made 
it into the specifications. At the moment the API animations are the 
same as CSS animations, and interleave with them according to start time.

 > Shane to draft specification for CSS integration.

Two things that Brian would like to see to be more confident about this:

 > Sydney team to start on an interoperability test suite based on a W3C 
testing technology.
 > Sydney team to look through Web Audio API, media-related APIs 
(especially recent ones) and check that the naming / idioms that we wish 
to expose don't conflict with these APIs, including things like ms vs. s.


5. TELCON TIME
==============

 > Thursday 5pm Sydney / 4pm Tokyo / 9am Leipzig roughly every 2 weeks

Next meeting 1 May 2014


6. CONVERSION TO BIKESHED
=========================
(Shane)

Motivation
-------------

I've been looking into moving the spec over to bikeshed. The main 
advantages:
(1) working off a maintained tool rather than patches on an old one 
(we'd get the same advantage from moving to ToT respec, of course)
(2) direct line to project owner. I've already contributed a number of 
features and ideas to Tab (detailed below). (Robin's pretty responsive too)
(3) pre-processed rather than on load. This makes publishing much 
easier, loading for readers faster, and you can still update-on-refresh 
with Ruby during development (or grunt-watch)
(4) by default bikeshed errors when names are undefined. It *always* 
warns. This is much nicer than respec, where you need to carefully check 
the source after editing
(5) markdown makes the spec source much more readable (respec has this 
apparently)

Changes I'm making to bikeshed
------------------------------

To ease the transition, I'm contributing a number of patches and ideas 
to bikeshed

(1) markdown lists <in progress>

You can type:

* item 1
* item 2

for <ul>

and

1. item 1
2. item 2

for <ol>

We're also developing a data list mode:

:cat ::a type of animal that purs
:dog ::a type of animal that barks

These play nice with multiple paragraphs and can be styled easily by 
wrapping in <div> tags.

(2) informative sections <proposed>

(3) Automatic section linking <complete>

(4) IDL processing <in progress>

Tab is reluctant to switch to our current approach here, so we've worked 
out a compromise that seems to work pretty nicely. Basically:

<div class='idl' attribute-info>
<pre>
interface AnimationTimeline {
     readonly attribute double? currentTime;
     AnimationPlayer play(optional TimedItem? source = null);
}
</pre>

<h4>Attributes</h4>

:<dfn>currentTime</dfn>
:: Returns the <a>time value</a> for this timeline or <code>null</code> 
if this timeline is <a>not started</a>.

<h4>Methods</h4>

:<dfn>play</dfn>
::Creates a new <a>AnimationPlayer</a> object ...

</div>

Brian: Is there a problem with these getting out of sync?
Shane: maybe we could have a warn-on-missing-members mode that generates 
an error if there are members in the IDL without descriptions or vise-versa.

Brian: Can I link to AnimationTimeline.currentTime from spec text?

Shane: Yes:

   <a attribute>currentTime</a>
   <a for="AnimationTimeline">currentTime</a>

 > Shane to fix <a>currentTime</a>

 > Shane to talk Tab into adding a tag for inserting an IDL interface 
summary

Next steps
----------

I've converted two largish sections over to bikeshed. I'm working on one 
example IDL section now, after which I'll upload a patch to demonstrate 
what the source will look like. We can decide what to do from there.



Next meeting, Thurs 1 May 2014 07:00 UTC 07:00
   Local time: 
http://arewemeetingyet.com/UTC/2014-05-01/07:00/Web%20Animations

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Tuesday, 15 April 2014 08:02:58 UTC