Consider adding a "behavior" option to scrollToIndex()

[domenic]

scrollIntoView() can take a behavior option, which is one of "auto", "instant", or "smooth". We should consider adding this to scrollToIndex() in the future, after #97 lands.

[valdrinkoshi]

I tried "behavior" on the html spec page - open the devtools and paste this in the console to scroll to the last element smoothly:

document.body.lastElementChild.scrollIntoView({behavior: 'smooth', 'block': 'end'});

It takes 25 seconds to scroll to the bottom - it will show ALL the content to the user, and slowly scroll to the desired element. If the element is closer to the current scroll position, it will arrive there faster.
In other words, the native scrollIntoView() keeps the velocity constant, and looks like it follows an ease-in-out transition.

I think that's cool! The only way to implement it like that would be to gradually update the positions until reaching the desired index - basically compute the keyframes of that animation ourselves.

[domenic]

Haha, wow, I'm glad you think that's cool. My first reaction was that it would be a bug in Chrome... It seems really unlikely that you'd actually want to wait 25 seconds to see your content? We should ask around, probably, before doing extra work to emulate that.

Note that the spec for scrollIntoView() is not that helpful:

When a user agent is to perform a smooth scroll of a scrolling box box to position, it must update the scroll position of box in a user-agent-defined fashion over a user-agent-defined amount of time.

[domenic]

• Firefox: scrolls with a nice animation curve taking ~2 seconds total
• Edge: can't seem to get it to work

I like the Firefox behavior personally...

[domenic]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=852549, we'll see what folks say. Still not sure what we should do in our case.

[valdrinkoshi]

I think that in either case we'd have to render intermediate content just for the sake of showing it while scrolling through it - otherwise we'd see the content we're leaving, a blank screen, and finally the element we wanted to scroll to.

[domenic]

My thinking was we could render a bit of intermediate content at the beginning and at the end, but in the middle the animation would be going at "infinite speed" and skip past the stuff in between. Not sure if that's doable.

[valdrinkoshi]

Here a quick demo of how I'm afraid it would look like to just render beginning and end - http://jsbin.com/qusihoq/1/edit?html,output
Even with higher speeds we might notice the blank space while doing "big jumps" with scrolling :/

Chrome	Firefox

[domenic]

If you try that in Firefox, it looks pretty reasonable, I think. Yeah, it'd be more perfect if all the text was there too, but it's OK.

I wonder if there are native apps using their equivalent virtual scrollers that we should be checking out? Or web apps, for that matter.

[valdrinkoshi]

Did a quick test on the iphone simulator, slowed down animations too

The approach I'd take to implement this would be:

1. render and position the destination element
2. use the native scrollIntoView() on it so we get the scroll animation "for free"
3. let the render loop do its thing as it receives scroll events (aka it renders the items in the current range)

The problem is how to recognize we are in scrollIntoView() mode, as during the scrolling we should not adjust the scroll size or the scroll position (things that we need to do normally, as we are using an estimated item size until we render the items). Once we reach the destination element, we can do all those.

Also, the user can interrupt the scrollIntoView() scrolling if he scrolls the opposite direction - that should be handled too.

In other words, I don't know how we could recognize that a particular scroll event was originated by user input (instead of programmatic scrolling).

[rakina]

Closing this as this is related to the virtual-scroller prototype implementation and we intend to make this repository focus on the standards side of it.