I have created a very very rough, first iteration of a proposal to add a Element.scroll method to the spec that will allow a developer to programmatically scroll an element with easing options.
Please see the explainer at: https://github.com/mkay581/proposal-element-scroll
I would love to get your thoughts!
@tabatkins, you seem to be a go to resource for getting answers in the forum. If not, please feel free to point me to someone else. What are some suggestions on this proposal?
There already is a specification for smooth scroll, which is implemented by Firefox. W3C / MDN
Returning Promise seems great, though.
Thanks @SaschaNaz for the link and the compliments. I did see that and that spec is great, but, unless Iâm missing something, it doesnât seem to account for scrolling individual elementsâonly the Window, as addressed in my proposal.
Is there any intention to add that API at the Element-level?
The same specification contains extension to the Element interface, which allows scrolling individual elements. http://www.w3.org/TR/cssom-view-1/#extension-to-the-element-interface
Ah, yes. I missed that partâsorry.
So it does look pretty solid.
The ScrollBehavior options donât give much flexibility. Iâd like to see more control of the scrolling behavior left up to the developer. And youâre right. It doesnât seem to have promises in there.
I wonder if the CSSOM has intentionally limited ScrollBehaviour to only âsmoothâ and âinstantâ so that user-agent can match the platform conventions in case of âsmoothâ. There is a hint of that in the spec but @zcorpan is the current editor and can shed some light there.
The proposed change suggests adding a easing function but not a duration. This feels incomplete to me in particular if the user agent decides to scroll with duration = 0 then the easing function becomes irrelevant! This would be a lot more powerful and flexible tool for scroll animations if it did support duration (and even delay) too. At which point, we probably want to have something that is actually part of Web Animation and not tacked onto the CSSOM scroll APIs.
Also I feel that a user-specified timing function makes sense only for a single element scroll operations but it may be inappropriate for âscrollIntoViewâ case where multiple elements may be scrolled (potentially in parallel).
+1 for returning a promise. Although it should be possible to polyfill that using âscrollâ event but there are a few corner cases which need to be covered (e.g., reaching to boundaries, scroll being interrupted by use input, etc.) which can make it tricky. This feels like a good extension.
I agree that a way to animate scroll positions without jank is missing from the platform. We (in Chrome) certainly are thinking about introducing new primitives for high performance animations which do include scroll position. This does not preclude adding other declarative options where it makes sense.
Yes, the options are intentionally limited so we can match platform conventions. It turns out that users get really used to how their platform of choice scrolls, and get pretty annoyed when individual apps or pages try to override it. (Thereâs some scrolling library in the wild that drives me crazy whenever itâs used, because itâs subtly but very noticeably different than how my Chromebook normally scrolls for slow pans.)
There has been explicit pushback from implementors at allowing webpages to customize scrolling behavior for this reason.
Understood, @tabatkins.
However, I donât think itâs a good idea refuse to implement a feature because we are afraid that developers will use it incorrectly or in a way that we did not intend. I also hate when websites hijack native scroll, but hijacking native scroll or user-initiated scrolls is not my goal here. In fact in the proposal I created, it explains that any user-initiated scrolls will cancel out any JS-initiated scrolls (along with any of their effects). I do think this is the same behavior of the existing Element scroll API also.
One of the bigger use cases is when a user visits urls that are mapped to anchors (sections) on a page. The jarring effect that happens when a user reloads the page or stumbles upon the url is undesirable and, in some cases, confuses the user, making it difficult to get a true sense of where they are on the page. Having these options gives the user a better sense of what section of the page the user is being taken to. This is just one use case, however. I go into a few more on my proposal (i.e. chat windows, etc)
I do think that promises are a good idea (as echoed throughout this thread). Should I open a request against the w3c/csswg-drafts repository for that?
I do think that promises are a good idea (as echoed throughout this thread). Should I open a request against the w3c/csswg-drafts repository for that?
Yes. That is the right place to open an issue.
UPDATE: Iâve created the cssom-view issue requesting that scroll methods return promises. Thanks @majidvp!