Intent to Prototype: Programmatic scroll promise
Mustaq Ahmed
Contact emails
mus...@chromium.org
Explainer
https://github.com/explainers-by-googlers/promisify-scroll
Specification
https://github.com/w3c/csswg-drafts/issues/1562
Summary
Web developers currently have no way to know when a programmatic smooth-scroll has completed. This feature provides a solution to the problem: make the programmatic scroll methods return Promise objects that get resolved on scroll completion.
Blink component
Blink>Scroll
Motivation
We have six scroll methods available through both Element and Window interfaces. These methods return immediately with the value undefined, which was fine during the early days of the web when scroll was assumed to be instant. This behavior no longer seems adequate from a web developer's perspective today: there is widespread support for smooth-scroll (see browser_compatibility [1] for the CSS property), and it is not easy for the developers to determine when a particular call for a smooth-scroll has completed. This feature makes the programmatic scroll methods return Promise objects that get resolved on scroll completion. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior#browser_compatibility
Initial public proposal
None
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Interop: Given the developers' support in the github discussion and the easy resolution in the CSWWG, we expect other major browsers to implement this feature in near future.
Compat: To maintain the backward compatibility for the scroll methods, we would avoid rejecting the returned Promises (as much as possible). This is because unhandled Promise rejections are treated as exceptions, which could fail any JS callers that assume that those methods succeed unconditionally.
Gecko: No signal
WebKit: No signal
Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/1562)
Other signals:
Interop: Given the developers' support in the github discussion and the easy resolution in the CSWWG, we expect other major browsers to implement this feature in near future. Compat: To maintain the backward compatibility for the scroll methods, we would avoid rejecting the returned Promises (as much as possible). This is because unhandled Promise rejections are treated as exceptions, which could fail any JS callers that assume that those methods succeed unconditionally.
Gecko: No signal
WebKit: No signal
Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/1562)
Other signals:
Security
None.
None.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Is this feature fully tested by web-platform-tests?
No
Flag name on about://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/41406914
Estimated milestones
No milestones specified