[cssom-view-1] Provide onAnimationEnd callback in scrollIntoView options

[CyberAP]

Spec

Right now you can't really tell if scrollIntoView scroll animation has finished nor you can't control the speed of the scroll and it might differ with each browser. So if you want to perform some action right after the animation has finished there's no determined way to do that. Having an onAnimationEnd callback as an initializer option would solve this problem:

Element.scrollIntoView({
  onAnimationEnd: () => Element.focus()
})

Why we would ever need that?

Imagine that you have some input you would like to focus that's out of the viewport boundaries right now, but you would also like to have a smooth scrolling animation to that input. If you execute focus before scrollIntoView then you'll get no scroll animation, because browser will
already scroll to that input without animation.

[jonjohnjohnson]

Methinks this should have the same solution as #156 - CSS Snap Points: Event Model Missing

[Dan503]

Is there any chance of element.scrollIntoView and window.scroll returning a promise that resolves when the scroll animation has ended? Or is that going to break backwards compatibility?

Applied to element.scrollIntoView

element.scrollIntoView({ behavior: 'smooth', block: 'start' }).then( scrollEvent => {
  console.log('The browser has finished scrolling')
})

Applied to window.scroll

window.scroll({ top: 0, left: 0, behavior: 'smooth' }).then( scrollEvent => {
  console.log('The browser has finished scrolling')
})

[fchristant]

The particular scenario mentioned by @CyberAP can be solved as follow:

CSS:
html { scroll-behavior: smooth; }

JS:

element.scrollIntoView(..params);
element.focus({preventScroll:true});

Without the preventScroll parameter, you are subject to browser quirks as below:

Firefox
Scrolls to the correct position (meaning, element.scrollIntoView) yet abandons smooth scrolling, even though the browser supports it. Not great, but at least the scroll position is correct.

Safari/webkit
Same as Firefox yet would not scroll smoothly in any case, as it's not supported. Not great, but at least the scroll position is correct.

Chrome
Chrome is the big offender here. It seems to cancel the scrollIntoView action altogether, instead does the smooth scroll from element.focus(), CSS based, and scroll position logic is based on that. In practice, this often means a wrong scroll position.

Other scenarios
Whilst preventScroll solves this particular scenario, I still very much agree we need a callback. If you need to do anything else after scrolling completes (say, run an animation), there's no robust way to do that right now.

[webdevelopers-eu]

There is another use case: when scrolling to particular element it is common that one must take in an account fixed-position headers. Unfortunately the very widespread solution is to have resizable fixed headers. E.g. tall header in the initial position and minimal header after a page was scrolled a bit.

That poses the problem with adjusting the target scroll position as the header changes size.

While one can easily use ResizeObserver to watch for header changes and adjust the target scroll offset accordingly there is no way to know when to stop and disconnect ResizeObserver after scrolling finished.

Ideally I would love to see

1. scrollIntoView() method return Promise
2. scrollIntoView() method honoring real-time changes to CSS scroll-padding property while scrolling is in progress

That way one can use ResizeObserver to update CSS properties and after scrolling finishes disconnect it.

[dnistreanuu]

Can we have it added to the language? The only solution to really detecting the scroll end is by preventing default and running event handlers synchronously. For example, if you have 2 Web Components controlling the same scrollbar and running scroll animation, they will both run without forcing it to run synchronously.

scroll, scrollBy, scrollTo, scrollIntoView - none of these has a callback, frankly, it's embarrassing that javascript doesn't provide callback for that.

I'd suggest adding 3 callbacks, isScrollStarted isScrolling isScrollEnded

[pft]

I second something like this, either via a callback or a promise. Currently we are left in the dark as regards whether a scroll event has ended.

Imagine the use case to want show an absolutely positioned element (e.g. with completion candidates) after focus. The final position of the element is not known beforehand, so the completion candidates are off. We by the way also had the scroll event hiding completion candidates. I circumvented that issue by substituting the wheel event for it, but have to see whether that really pans out quite as well. If we could focus after scrolling into view, there would be no scroll event at that point, so it would also work with the original scroll event.

[Kymy]

hey @Dan503 were you able to fix your scenario? I'm looking for a solution like the one you suggested

[Dan503]

@Kymy no, I think I ended up just using setTimeout which is far from perfect but it is close enough to do the job for now.

element.scrollIntoView({ behavior: 'smooth' });
setTimeout(() => {
  console.log('The browser has (theoretically) finished scrolling');
}, 500)

[Dan503]

I get the feeling the solution I mention above (using a promise) is going to break backwards compatibility since element.scrollIntoView will go from returning a falsy value (undefined) to a truthy value (a promise).

In that case, it should be safe to just add a new callback option to the options object.

element.scrollIntoView({
    behavior: 'smooth',
    onScrollEnd: (scrollEvent) => {
        console.log('The browser has finished scrolling');
    } 
});

Then if developers want it in promise format we can make a simple utility for it:

function scrollElemIntoView(elem, options) {
    return new Promise((resolve, reject) => {
        if (!elem) {
            reject("Cannot scroll as the target element does not exist");
            return;
        }
        elem.scrollIntoView({
            behavior: 'smooth',
            onScrollEnd: resolve,
            ...options
        });
    })
}

scrollElemIntoView(element, { block: 'start' }).then( scrollEvent => {
  console.log('The browser has finished scrolling')
})

Actually the options object is probably also better because you can have onScrollStart, onScroll, and onScrollEnd callbacks to have finer control over when the callback is triggered as mentioned in this comment:
#3744 (comment)

[ivanduka]

@Kymy no, I think I ended up just using setTimeout which is far from perfect but it is close enough to do the job for now.

element.scrollIntoView({ behavior: 'smooth' });
setTimeout(() => {
  console.log('The browser has (theoretically) finished scrolling');
}, 500)

Unfortunately, this is highly unreliable. The scrolling easily can take more than 500ms even for a very short content because the browser can be resource-constrained by other heavy pages or even general OS load, the chaces of this happening are even higher on mobile devices.
The only reliable way to do it as of now is not to use behavior: 'smooth' until we have a callback-based solution.

[Dan503]

Unfortunately, this is highly unreliable. The scrolling easily can take more than 500ms even for a very short content because the browser can be resource-constrained by other heavy pages or even general OS load, the chaces of this happening are even higher on mobile devices.

That's why I said far from perfect.

[csicky]

It is not always about adding focus after scroll into view. I arrived here because I have two lists and when I click on item in one, I scroll to the corresponding item in the other list. When the scroll to element completes, I add an animation class to make the element highlighted. Problem is I don't know how much timeout to use as the list is dynamic and scroll is smooth. I can't know how much it will take. If the list is long a short timeout will make the animation class be done by the time the scroll completes. If the timeout is too big, the animation will happen later than expected.