- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 10 May 2013 13:05:46 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 9 / 10 May 2013 Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.QkrEzElmrGJ/latest Present: Doug, Shane, Steve, Brian Agenda: 1. Keyframe interfaces 2. Adjusting keyframe list internals 3. Style sheet interactions 1. KEYFRAME INTERFACES ====================== Discussion: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0088.html Current proposal: - Make composition operation per-frame instead of per-value. Do we still need the Keyframe dictionary in this case? Shane: What would we lose if we dropped the dictionary? Brian: We would lose (a) bindings for non-ECMA languages without the dictionary. We would also lose (b) some simplicity in handling the return values from the API: the client code would have to iterate over the object's *properties* and take care to ignore the 'offset' and 'composite' properties. With the dictionary they simply iterate over the values array. (i) With dictionaries dictionary Keyframe { sequence<KeyframeValue> values; double? offset = null; CompositeOperation? composite = null; }; dictionary KeyframeValue { DOMString property; DOMString value; }; var frames = effect.getFrames(); frames.values.forEach(...); (ii) With the shortcut dictionary-like-thing KeyframeShortcut { <property-name>: <value> ... double? offset = null; CompositeOperation? composite = null; } var frames = effect.getFrames(); for (var prop in frames) { if (prop != 'offset' && prop != 'composite') { ... frames[prop] ... } } Steve: If in doubt, leave it out. > Let's switch to just the shortcut for now and describe the alternative in a note in the spec. 2. ADJUSTING KEYFRAME LIST INTERNALS ==================================== While reviewing the way effect animated values are generated from keyframe lists, we realized that it makes little sense to limit keyframe offsets to the range [0, 1], given that we allow itming functions to produce iteration fractions outside this range. Plus removing this restriction makes things simpler (and easier to reason about) ... * allow any offsets, not just those between 0 and 1 * where there are at least two keyframes available, extrapolate existing segments rather than creating new virtual keyframes at 0 and 1 where necessary * special case only the single-keyframe case to add a single virtual keyframe at offset 0 with neutral add and set values. (What about if a single keyframe is supplied at offset 0?) * Always space keyframes with missing offsets between the closest (in list order) neighbours with offsets rather than working only if sorted. (What about keyframes with missing offsets at the ends of the list? It no longer makes sense to place them at offsets 0 and 1.) So for example ... [{offset: 0.2, width: 100px}, {offset: 0.7, width: 200px}] - set width: 60px at offset 0 - set width: 260px at offset 1 [{offset: -0.4, width: 100px}, {offset: 1.2, width: 180px}] - set width 120px at offset 0 - set width 170px at offset 1 [{offset: 1, width: 100px}, {width: 80px}, {width: 20px}, {width: 50px}, {offset: 0, width: 200px}] - equivalent to width: [200px, 50px, 20px, 80px, 100px] [{offset: 0.5, width: 100px}] - add virtual keyframe at offset 0 with value add and set values of 0 - width is '200px - <underlying>' at offset 1 for x = 2, (<underlying> + <add>) * (1 - x) + <set> * x = 2 * <set> - <underlying> - <add> Brian: What happens here? (a) [ { offset: 0.7, width: 100px } ] Answer: Interpolates from <underlying> -> 100px -> (1 + 0.3/0.7) * 100px - 0.3/0.7 * underlying Brian, are you proposing we allow the following? Input: null, 0.4, null, null, 0.7, null, 0.3, null Answer: Yes. Sure, it's non-sensical, but we can do something reasonable. If you remove the nulls then it's reasonable that we sort it so it's just an extension of that case. Discussion about special-case behaviour for a single value and how it does/doesn't parallel with CSS. Basically, we have two options: A) Match CSS' conceptual model and only allow keyframe offsets in the range [0..1]. In this scenario we fill in values at 0 and 1 as necessary. Shane: (but it isn't really CSS' conceptual model because they do snapshotting and we don't) The following: [ { 0.3, left: 100px }, { 0.7, left: 200px } ] Gives: <underlying> -> 100 -> 200 -> <underlying> B) Allow values outside [0..1] and deviate from CSS' model here The following: [ { 0.3, left: 100px }, { 0.7, left: 200px } ] Gives: left: 25px at 0 and 275px at 1 Brian is concerned about deviating from the CSS' conceptual model in this regard. Shane & Steve are concerned about not allowing authors to have proper control over values reached when the time fraction is outside the [0..1] range > Let's give it a little more thought. 3. STYLE SHEET INTERACTIONS =========================== There are three main things here: 1) It seems like you really want to use the 'least processed' available numeric value as an underlying value. For example, transform(100px, 100px) becomes a computed value of matrix(1, 0, 0, 1, 100, 100) - you really want to take the specified value here. On the other hand, 'red' becomes a computed value of rgb(255, 0, 0) - red isn't numeric but the computed value representation is. Discussion: actually, computed value of transform property is "As specified, but with relative lengths converted into absolute lengths." All: hooray! 2) We can't interpolate to style-recalc sensitive values like width:'auto' (or for that matter 'currentColor') because we don't know what those values are going to be when the animation is finished. All we can do is animate by stepping from the underlying value to 'auto'. For symmetry we should probably say that you can't interpolate from style-recalc sensitive values either. Discussion: Maybe you can for colours. If you have a computed value then you can interpolate to it. We just need an internal representation of "half-way between red and current color". ACTION: Shane to see if you can now transition to/from auto in CSS. 3) We need to add prose to indicate that the override style sheet must be regenerated on every style recalculation, not just on every animation frame. Otherwise examples like this will be incorrect: <style> .outer { width: 400px; } .inner { width: inherit; } <div class="container"><div class="outer"><div class="inner"></div></div></div> <script> var p = document.timeline.play(new Animation(document.querySelector(".inner"), {width: 100px}, 2); setTimeout( function() { p.pause(); document.querySelector(".outer").style.width='300px'; }, 1000); </script> ACTION: Shane to make that change. Next meeting: Mon May 13 18:00 PDT / Tues 14 May 11:00 AEST / Tues 14 May 10:00 JST @ https://etherpad.mozilla.org/GExuzZaLRE Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 10 May 2013 04:06:17 UTC