[web-animations] when are keyframe values resolved?

[graouts]

This issue stems from web-platform-tests/wpt#37053 where I was asking about the intended behavior of a WPT test that essentially boils down to this little reduction:

const element = document.body.appendChild(document.createElement("div"));
element.style.fontSize = "40px";
element.animate({ "lineHeight": ["40px", "calc(40px - 2em)"] }, 1000);
element.currentTime = 500;

What is the value of line-height?

As of this writing, Chrome will compute the value as the 50% value between 40px and -40px (the unclamped output of calc(40px - 2em)) and resolve 0px.

Meanwhile, Firefox and Safari will resolve 20px, the 50% value between 40px and 0px (the clamped output of calc(40px - 2em)).

The difference here is that Safari (and I expect Firefox as well) will fully resolve the calc() value before using it as input to interpolating the animated value, whereas Chrome will not do so.

Of note, the CSS Values and Units spec has this to say in the Range Checking section for calc():

Parse-time range-checking of values is not performed within math functions, and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from an expression must be clamped to the range allowed in the target context.

Should that mean that the calc() value here should be clamped for the allowed range, which the line-height definition clearly states should be non-negative?

I think it would be good for the Web Animations specification to at least have a note accounting for this.

Note that I raised #8158 which discussed a similar issue in the context of mix().

[andruud]

Should that mean that the calc() value here should be clamped for the allowed range, which the line-height definition clearly states should be non-negative?

Yes. Chrome is IMO wrong here. We are supposed to "compute" that value the same way "the" computed value is produced for line-height, per 5.3.2.

Regarding the more general question of "when keyframes are resolved" (from the title of this issue), this was mostly clarified in #5125 and the PR that resulted from that.

[graouts]

Filed web-platform-tests/wpt#37457 to update the relevant WPT tests to match the current spec state.