Currently we merge keyframes when calling getFrames(). This is due to the way we store animation segments. The spec however requires we merging only on input and only for property-indexed keyframes (and possibly CSS although this is yet to be specced). Basically, if we have the following input: { offset: 0, left: '100px' } { offset: 0, left: '200px' } { offset: 0, left: '300px' } { offset: 0.5, left: '400px' } { offset: 0.5, left: '500px' } { offset: 0.5, left: '600px' } { offset: 1, left: '700px' } What we should get back is just: { offset: 0, left: '100px', easing: 'linear' } { offset: 0, left: '200px', easing: 'linear' } { offset: 0, left: '300px', easing: 'linear' } { offset: 0.5, left: '400px', easing: 'linear' } { offset: 0.5, left: '500px', easing: 'linear' } { offset: 0.5, left: '600px', easing: 'linear' } { offset: 1, left: '700px', easing: 'linear' } The reasoning being that the more we try to tidy up the keyframes in between setFrames and getFrames, the harder it is for the author to reason about and know what to expect. They can't pass in an array and keep using the same indices on the output. (That's also why the spec says we shouldn't expose the synthesized 0/1 keyframes although there might be an argument for changing that. I'll file a separate bug for that.) The other reason is that once we introduce paced timing, the computed offsets can change due to the target element's font-size etc. If we use the computed offsets to do merging on output then we'll get different numbers of keyframes for the same input over time. Instead, the spec says we do merging once on input using distribute spacing (but we'll use the specified spacing mode when we actually come to calculate computed offsets) and only for property-indexed keyframes. Our current behavior should produce the correct visual result and not be observable for the subset of the API we plan to ship with Element.animate but once we come to ship getFrames() we'll need to update to match the spec.

This is being fixed in bug 1245748 (although the part that actually exposes this to getFrames) has yet to land.