- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 15 Apr 2014 17:02:27 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
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