Feature Request: ability to "continue" scrolling if needed

[matthew-dean]

One of the things I wish I could do is alter the scrolling mechanism or skipping elements to scroll based on certain conditions, but the side-effect of attaching a function to behavior is that it effectively interrupts all scrolling. It would be nice to alter the list of elements to scroll, and where they will scroll to, but then pass the action back to the library, since it already polyfills smooth scrolling. Otherwise, if I use behavior: Function, then I have to additionally polyfill smooth scrolling, even though it's polyfilled in your library internally. It would be nice to say back to scrollIntoView, "yes, continue scrolling this and this element smoothly, although change element 2's eventual scroll position. And no, don't scroll element 3." And then the magic just continues from there.

[matthew-dean]

I think what you should probably do is, rather than have a function as behavior, leave the other values for behavior and then have something like beforeScroll with the entries. Returning true should just execute normal behavior. Returning an object should change what is scrolled and to what scroll values.

[stipsan]

This is something I've wanted as well. It's mentioned shortly after the initial v2 release:

For those who want to skip some overflow elements, but not all, I plan on introducing another callback option for that, similar to options.boundary where you can make your own assertions and decide what should count as a scrolling box or not.

It would be super nice to just be able to skip certain elements and have everything just work™ instead of needing to reimplement so much functionality. This feature would belong in compute-scroll-into-view though, to ensure the scrolling coordinates are correct when elements are skipped.

Instead of calling it beforeScroll how about shouldScroll?