Attempting a native scrollbar for the virtual list view

[pichfl]

Since I wanted to use list-view in a few projects over at anfema, I tried to wrap my head around a way to add a native scrollbar to virtual listviews.

I thought it might be wise to discuss or gather previous attempts before I start implementing my own solution.

My idea so far is basically a reverse of the concept of Antiscroll - Make a container for just each scrollbar predicting the scrollbar size where possible, add a spacer element to get the right overflow size and listen to the scroll event to adjust the scroll position of the list-view or set scrollTop/Left when the list-view is scrolling. It might be wise to limit/throttle the scroll events, but other than that it seems like a very feasible solution.

A trade-off for this scenario would be a small amount of dead space where the scrollbars would be if the platform hides them by default (Safari, Mobile Browsers). Maybe we can use pointer-events:none to counter-act this for most cases (IE < 11 does not support the css property)

While I'm quite clear on how to add this to the component (seriously, writing code for Ember is just great), I'm not sure if the trade-off makes this solution a perfect candidate to be included by default, so should I implement it as another subclass then?

Would be nice to hear your thoughts on this.

[taras]

This is very interesting.

reverse of the concept of Antiscroll

Is it reverse in what it will do or reverse in how it works?

Is the intention to allow scrolling the page and thereby scrolling the content inside of the list-view?

[stefanpenner]

why not just use non-virtual?

[pichfl]

@taras I should have clarified that: Antiscroll adds custom scrollbars to an element by wrapping the element in a container, hiding the regular scrollbars in the overflow. This way all native scrolling behaviour for the element is retained.

For the virtual-list-view, we already have simulated scrolling behaviour, so we pretty much want the opposite of Antiscroll, showing native scrollbars for virtual overflow like I described in the ticket. The scrollbars would still be with the element, not somewhere else on the page, as I just wanted to bring the virtual view on the same level as the regular one.

@stefanpenner We have a lot of users on iPhone and iPad, so preventing any lag would be preferred. If the non-virtual view no longer suffers the problems described in the first paragraphs of the README, I'll happily switch over :smile:

[stefanpenner]

I believe recent iOS sorted out the main problem. It would be worth seeing how your app performs

[pichfl]

We don't use list-view right now (doing a lot of pagination), but I'll see if can try it's current version in a branch and/or create a testcase for our scenario.

However, while iOS 8 is great (and solves at least this problem for me), I'm not so sure about Android or the behaviour found in #229 though. If you think those concerns become invalid with the latest version of list-view, feel free to close this ticket, if not, I'll give it a shot and try to extend virtual-list-view.

Edit: I just learned that Chrome on Android fires the scroll event correctly, but funnily enough, if you run your app as a Web Clip in iOS, it won't fire the events correctly as Web Clips will use the older rendering engine.