Re: [web-animations] KeyframeEffect processing

Suppose a user has fill: both and the following keyframes:
  keyframe A - no offset
  keyframe B - offset -1
  keyframe C - offset 2
  keyframe D - no offset

If (when) we provide support for values outside 0..1, the user would likely
want keyframe A to receive offset -1 and keyframe D to receive offset 2.

Possible rules to achieve this would be:-
(a) Always throw an exception if provided offsets are not sorted.
(b) If the last frame has no offset, assign it the maximum of 1 and the
highest supplied offset.
(c) If the first frame (still) has no offset, assign it the minimum of 0
and the lowest supplied offset.

This could be called option (3).


As we don't currently support values outside 0..1, and we can become more
lenient (but not stricter) later, we would want the same rules for now as
Shane's option (1):-

(a) Always throw an exception if provided offsets are not sorted, or any
are outside [0,1].
(b) If the last frame has no offset, assign it offset 1.
(c) If the first frame (still) has no offset, assign it offset 0.





On Thu, Jul 10, 2014 at 10:23 AM, Shane Stephens <shans@google.com> wrote:

> Hi list,
>
> Web Animations defines a KeyframeEffect, which allows developers to
> specify animations as a series of keyframes (similar to CSS Animations).
>
> Each input Keyframe contains one or more CSS property:value pairs, and an
> optional offset that specifies the fractional position of the keyframe, e.g.
>
> new KeyframeEffect([
>     {left: '100px', top: '200px', offset: 0.4},
>     {left: '200px', top: '100px'}]);
>
> The processing of Keyframes as currently specified is quite complicated:
> (1) if there are keyframes without offsets, and the keyframes with offsets
> are not in order, then throw an exception
> (2) if the keyframes are not in order then sort them
> (3) throw away any keyframes with offsets outside the range [0, 1]
> (4) if the first keyframe has no offset, give it an offset of 0. If the
> last keyframe has no offset, give it an offset of 1.
> (5) space any keyframes without offsets (either by evenly distributing
> them or by pacing them).
>
> Furthermore, when KeyframeEffects are used with easings that produce
> timing fraction values outside the range [0, 1], we need to reconstruct
> behavior by extrapolating the first two or last two Keyframes for offsets
> outside [0, 1].
>
> We feel there are two problems with this:
> * it isn't easy for an author to understand when keyframe data is used,
> when it is silently dropped, and when an exception might occur.
> * we silently drop keyframes outside [0, 1] (i.e. throw away explicit data
> provided by the author) then reconstruct linear default behavior based on
> keyframes that already have another purpose (i.e. replace explicit data
> with an algorithm with inputs that can't be tweaked easily).
>
> Accordingly, we'd like to do better here. There are two options:
>
> (1) be extremely strict. Always throw an exception if offsets are out of
> order, always throw an exception if offsets are outside the range [0, 1].
> This way an author immediately knows if they are providing information that
> isn't going to be used.
>
> (2) be extremely accepting. Distribute offsets before sorting, never throw
> an exception, and never throw away data outside the range [0, 1] (in fact,
> use a constant value outside this range if no data is available). See
> details below.
>
> My personal preference is to go with (1) for now as it is easy to replace
> it with (2) in later versions of the specification. However, I'd like to
> hear other opinions too - in particular, given there is a clean and
> efficient way of handling essentially any input, should we be doing that
> now rather than being strict?
>
> ---
>
> details of (2):
>
> We would process keyframes according to the following steps:
> (1) If the first keyframe has no offset, give it an offset of 0. If the
> last keyframe has no offset, give it an offset of 1.
> (2) space or pace any remaining keyframes without offsets
> (3) sort all keyframes in offset order
>
> ---
>
> Cheers,
>      -Shane
>