[web-anim] Web Animations minutes, 9 / 10 May 2013

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