Is requestAnimationFrame called at the right point? #2569
Description
I'm repurposing this slightly.
Currently the spec says that requestAnimationFrame callbacks should come before the very next render, unless requestAnimationFrame is called after the browser has started processing the raf callback queue, in which case the callbacks happen before the following render.
Chrome & Firefox do this, but Edge and Safari don't. They run requestAnimationFrame callbacks before the following render.
test.style.transform = 'translate(0, 0)';
document.querySelector('button').addEventListener('click', () => {
const test = document.querySelector('.test');
test.style.transform = 'translate(400px, 0)';
requestAnimationFrame(() => {
test.style.transition = 'transform 3s linear';
test.style.transform = 'translate(200px, 0)';
});
});In Edge and Safari, the box will move to the left. In Chrome and Firefox (spec compliant) it'll move to the right. Demo.
Developers are pretty confused about this, with currently 60% expecting the Edge/Safari behaviour.
Should we do something about this?
Here's the original issue text:
It's currently impossible to request a callback for the next animation frame.
requestAnimationFrame(cb) will call cb before the next visual update in most cases, unless it's called during "run the animation frame callbacks", in which case it'll be called after the next visual update.
Sometimes you want to wait until after a natural layout/render to perform particular steps, to avoid a synchronous layout.
function requestNextAnimationFrame(cb) {
requestAnimationFrame(() => requestAnimationFrame(cb));
}The above guarantees cb will be called after a natural layout/render, but if called during "run the animation frame callbacks" you end up waiting an additional frame.
Another way to solve this problem would be to provide insight into the current position within the event loop, so a user-land implementation of requestNextAnimationFrame could avoid calling raf twice if it's already in that phase of the loop.