Open markcellus opened 7 years ago
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:
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.
Smooth scrolling has been introduced into the spec where the scroll happens over a period of time, which is great. However, I think it would be even more useful if scroll method returned a promise so the developer could wait until the scroll finishes before moving on to next set of tasks for things like triggering analytics data after scrolling, unloading resources when they've been scrolled out of view, parallax scrolling, etc.
Obviously
scroll()
ing an element that hasscroll-behavior
option set toauto
makes scroll instant and is therefore not inherently asynchronous. But I think, to keep the API consistent, the scroll method should return a promise every time it is used.So if you had the following HTML...
you can do this...