Bug 212409

Summary: [Web Animations] CSS-originated and JS-originated keyframe animations with implicit values behave differently
Product: WebKit Reporter: Antoine Quint <graouts>
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: dino, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
CSS Animations test
none
Web Animations test
none
Test none

Description Antoine Quint 2020-05-27 07:34:51 PDT
Consider this example:

    const keyframes = { left: "500px" };
    document.querySelector(".single").animate(keyframes, 1000);
    document.querySelector(".duplicate").animate(keyframes, 1000);
    document.querySelector(".duplicate").animate(keyframes, 1000);

In this example, the .single and .duplicate elements will not have the same "left" value during the span of the animation as the second animation for .duplicate will use the "left" value animated by the first animation as the implicit "from" value.

However, the same example written using a CSS Animation will behave differently and .single and .duplicate will have the same animated value for each frame. I haven't checked, but I think this is due to our resolving values for implicit keyframes for CSS Animations when they start rather than at run time.

I was a little baffled though by the fact that both Firefox and Chrome will return a static "from" value when calling getKeyframes() on the individual animations. That doesn't seem to make sense, I'd expect the "left" value ought to be left out or computed to be what is current.
Comment 1 Antoine Quint 2020-05-27 07:35:11 PDT
Created attachment 400334 [details]
CSS Animations test
Comment 2 Antoine Quint 2020-05-27 07:35:29 PDT
Created attachment 400335 [details]
Web Animations test
Comment 3 Radar WebKit Bug Importer 2020-05-27 07:35:55 PDT
<rdar://problem/63674292>
Comment 4 Antoine Quint 2020-05-27 08:14:26 PDT
Created attachment 400337 [details]
Test
Comment 5 Antoine Quint 2020-05-27 08:20:20 PDT
I think WebKit might actually be correct for its runtime behavior due to this excerpt from section 3 of the CSS Animation 2 spec (https://drafts.csswg.org/css-animations-2/#keyframes):

    6. If there is no keyframe in keyframes with offset 0, or if amongst the keyframes in keyframes
       with offset 0 not all of the properties in animated properties are present,

        1. Let initial keyframe be the keyframe in keyframes with offset 0 and timing function default
           timing function. If there is no such keyframe, let initial keyframe be a new empty keyframe
           with offset 0, and timing function default timing function, and add it to keyframes after
           the last keyframe with offset 0.

        2. For each property in animated properties that is not present in some other keyframe with
           offset 0, add the computed value of that property for element to the keyframe.

This leads me to think that we are correct in specifying the implicit keyframe's values when the animation is created. However, as the newly attached test shows, we are not reflecting this in the getKeyframes() output since there is "left" property for the implicit keyframes, unlike Firefox and Chrome.
Comment 6 Antoine Quint 2020-05-28 02:12:09 PDT
This spec text only applies to the output of getKeyframes(), the runtime behavior should be that the underlying value is used as set for each animation sample.