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().
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3