[scroll-animations-1] Handling changed size/position in current frame #8694
Description
In issue #5261 we defined a mechanism for ensuring that scroll and view timelines that were discovered during style and layout were given an opportunity to produce a current time for the frame in which they were first rendered, however with view timeline ranges being usable from both animation-range and from keyframes, the particular progress of an animation depends on layout.
For example, consider the following (demo):
<style>
.subject {
view-timeline: subject;
}
.shifted {
top: 120vh;
}
.grown {
height: 300px;
}
@keyframes slide {
entry 0% {transform: translateY(100vh);}
exit 0% {transform: translateY(0);}
}
#animated {
animation: slide linear;
animation-timeline: subject;
}
</style>
<div class="subject"></div>
<div id="animated"></div>
<button class="shift">Shift</button>
<button class="grow">Grow</button>
<script>
document.querySelector('.shift').addEventListener('click', () => {
document.querySelector('.subject').classList.toggle('shifted');
});
document.querySelector('.grow').addEventListener('click', () => {
document.querySelector('.subject').classList.toggle('grown');
});
</script>When the shifted or grown classes are added (e.g. by clicking the buttons) we need to update the offset of the exit 0% keyframe as well as invalidate the animation and calculate the new position for the #animated box.
We have two options:
- Allow animation to be out of date on the frame in which geometry changes occur. Schedule another frame and allow for some flicker.
- Detect changes in the geometry and allow rerunning style and layout. We could do this in a similar way to how we re-run the lifecycle for newly detected animations (see [scroll-animations] Behavior of scroll-linked animations in the first frame #5261).
I think that unless an animation caused the animation to change I would not expect a flicker when a style change results in the subject moving. As such, I suggest pursuing option 2. More concretely, after running resize observers (to take into account developer derived sizes), we would need to check if the animation constraints have changed (in addition to checking for new scroll timelines as we already do) and if so rerun style and layout to incorporate the updated animations. This is not ideal for performance but hopefully will not happen often.