Extending ScrollOptions to include duration

I have a use case for smooth scrolling: I show log file text (potentially many lines) in a container, along with a sort of index alongside. When a user clicks an entry in the index, we scroll to a given line in the log text. This is a natural use case for smooth scrolling as provided in the CSSOM View Module: I want to scroll to the appropriate line while giving the user context as to where the new scroll position is relative to the original position. However, if the new scroll position is on a line far down the document from the current scroll position, the smooth scroll operation can take several seconds to complete in Chrome.

I’d like to propose something like a duration property be added to ScrollOptions to allow a developer to cap the amount of time the user agent spends scrolling to the destination.

Does anyone know if this is against any original design tenet of “smooth” scrolling in this spec? I understand from this conversation that we want to honor the system’s scroll style that the user is presumably used to, but I think my example above demonstrates bad UX.

I think my example above demonstrates bad UX.

If scrolling is set to move too fast, you’ll potentially cause the screen to pass the three flashes-per-second threshold which is an accessibility violation.

If it’s important for your users to get to the information quickly, consider not using an animation.

Have you filed a bug against chromium? Maybe they agree that it’s universally bad UX, and can fix it for everyone by default.

Maybe browsers could offer a scroll behavior option that sits between full animation and no animation. For example, the browser could instantly jump 99% of the way but then do a animation for that last ~50 pixels. That way, the user would get a hint in which direction the scroll happened.

So, the behavior actually seems to be a lot better in Canary (Chrome 82).

Seems to take more or less a constant amount of time to scroll between two offsets after a certain point. Haven’t tried it in other browsers though.

So maybe this isn’t appropriate for the specification but more on the user agent not to implement in a way that could be bad for the user.