FWIW, here is a link to the relevant discussion where others have also +1'd this feature.

in 2018 it is still very much needed, only now we will use it this way:

let element = document.getElementById('scroll-container');
await element.scroll(0, 400);
// ...scroll has finished

use case: set focus after scroll

Since all of the scrolling methods currently return void, they're very compatible with being upgraded into returning promises. I think this would be a fine feature, we just need implementor interest. I'll Agenda+ it to gauge support.

The Working Group just discussed Consider making scroll methods return promises, and agreed to the following:

• RESOLVED: add returning a promise to all scroll functions

Is there an ETA for this being spec?

Unlike TabAtkins' opinion in the IRC chat, I strongly support the idea of implementing Promise rejection if a scroll is interrupted.

As I mentioned in #3744 , the intended effect of scrollIntoView is to bring the specified element into view. If this does not happen for any reason, the promise should be rejected, as the action was not fulfilled. There are specific scenarios where this should occur, such as:

• The element is removed or stops being rendered before it reaches the visible part of the viewport.
• The smooth, time-dependent scrolling is interrupted programmatically or by user action.

Simply put, the goal of scrollIntoView is to bring an element into view. If this is achieved, the promise should be fulfilled; if not, the promise should be rejected. This aligns with the natural and expected behavior that any programmer would anticipate when triggering an action intended to produce a specific result.

If this is achieved, the promise should be fulfilled; if not, the promise should be rejected.

This is a valid point @webdevelopers-eu. But I think throwing an error may be unexpected for these cases and developers are probably likely to miss handling it. Is it possible to just abort/cancel the promise instead? That would make it so that an app handles this gracefully (by default) instead of abruptly throwing an error, which could potentially cause an entire website from working if the website is a SPA (or relies a lot on JS to operate).

In that case, @markcellus, I can't see any other situation where a Promise rejection would occur, which essentially reduces the Promise to just being a callback. This undermines its purpose, as Promises are intended to handle success and failure cases, not just one. If we’re only using it to signal success and merely aborting in failure scenarios, we strip away the robustness of the Promise pattern and lose the benefit of built-in error handling.

In an async function, the promise is rejected only when the function throws an error. All other cases result in a fulfilled promise. This pattern is generally followed by other DOM functions that return promises; rejection is reserved for errors where we'd throw in a synchronous function.

In this case, we're just using the promise for its timing aspect.

In this case, we're just using the promise for its timing aspect.

Additionally, the promise can be passed an argument which includes the completion status of the scroll so that developers can choose to have different behavior depending on whether the scroll was completed or interrupted.

While implementing this, we found two Blink tests that are affected by a minor error handling change caused by this proposal here. I don't expect this corner case to be a compat problem, and wanted to check what other folks here think:

A JS parsing error caused by a malformed scroll*() call would no longer throw synchronously; instead it would return a Promise that would throw asynchronously. For example, in Blink the shouldThrow('window.scrollTo(x)') call here fails because the eval() is seeing a Promise object instead of an exception.

Anyone concerned?

I'm not too concerned, since that's a mistake in the first place and would be fixed by the author. Only places explicitly catching a thrown error and doing something meaningful with it would notice.