The <transform-list> syntax enables custom properties to animate like the transform property.
One quirk of transform is that the serialisation procedure requires layout information in order to turn percentages of the element's box dimensions into a matrix.
Unfortunately this procedure requires layout information to turn an animation between translateX(100%) and rotate(45deg) into a single matrix. There is currently no way of representing such a value in CSS independent of what the layout is. You would need something like blend(translateX(100%), rotate(45deg), 0.5).
Here's a more concrete example:
<!DOCTYPE html>
<style>
#target {
/* Animation is paused at halfway. */
animation: x 1s -0.5s linear paused;
--y: var(--x);
}
@keyframes x {
from { --x: translateX(100%); }
to { --x: rotate(45deg); }
}
</style>
<div id="target"></div>
<script>
CSS.registerProperty({
name: '--x',
syntax: '<transform-list>',
initialValue: 'none',
});
// What should the computed value of --y be?
console.log(getComputedStyle(target).getPropertyValue('--y'));
</script>
Should the serialisation of the computed value of <transform-list> custom properties be the same as transform and depend on layout computations?
Should this layout computation dependency "infect" other custom properties that reference it via var()?
What happens when we try to serialise a <transform-list> custom property inside a layout worklet in the middle of layout computation?
I don't think depending on layout computation is a good idea here.
I recommend using <transform-list-2> := <transform-list> | blend(<transform-list-2>, <transform-list-2>, <number>) instead (but with a better name) and to serialise it as the original transform functions instead of as a matrix that incorporates layout computations.
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.4