This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26909 - Scrolling in one direction aborts smooth scroll in the other direction
Summary: Scrolling in one direction aborts smooth scroll in the other direction
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM View (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
Depends on:
Reported: 2014-09-26 09:47 UTC by Simon Pieters
Modified: 2014-09-29 09:13 UTC (History)
1 user (show)

See Also:


Description Simon Pieters 2014-09-26 09:47:53 UTC

Consider an ongoing smooth scroll:

scroll({top:100, behavior:"smooth"});

and then before the scroll is finished, another scroll in the other direction:

scroll({left:100, behavior:"smooth"});

Should it abort the first scroll or not?
Comment 1 Kearwood "Kip" Gilbert 2014-09-26 14:59:02 UTC
In our implementation, the second smooth scroll aborts the first.  The animation of the scroll position incorporates the velocity of the first scroll, resulting in a momentary overshooting on the y-axis while the x-axis animation advances towards the new "left:" position begins.  The y-axis of the scroll at the time of the abort is used as the new destination's y-position for the new smooth scroll in the absence of a "top:" member in the ScrollToOptions dictionary.

Effectively, we respect CSSOM View's 4.1.1 rule, "Abort any ongoing smooth scroll for box.", while providing a smooth transition into the new animation.

Are there some use cases where other behavior would be more desirable?

If so, would it be reasonable to explicitly stop the first animation before instantiating the second?  One method would be to allow the smooth scrolls to be explicitly stopped instantly with a call such as:


(In our implementation, this would stop the scrolling motion immediately)

This would work inherently if we always use the scrollX and scrollY positions at the time of the aborted smooth scroll as the default destination for subsequent instant or smooth scrolls when they are not specified in the ScrollToOptions dictionary.  This would also allow explicitly aborted smooth scrolls to be stopped with a smooth transition:


(In our implementation, this would result in a momentary overshoot in the current direction of travel before returning to the position at the time of the aborted smooth scroll.)

TL;DR, Yes.
Comment 2 Simon Pieters 2014-09-29 09:13:39 UTC