4 ms·

For those wandering why this is an issue. If you are using virtualised scrolling [0] to display a very long list of items, this limits the maximum length of the

For those wandering why this is an issue. If you are using virtualised scrolling [0] to display a very long list of items, this limits the maximum length of the scrolling area, and therefor the maximum number of items. Say you have a display that will show all items in a database, each row is 20px high, this limits the maximum number of items you can show to 894,784. That may seem absurd, but if you have a UI that allows you to jump to a specific item in the scrolling list, you would expect to be able to do it. 0: https://blog.logrocket.com/virtual-scrolling-core-principles-and-basic-implementation-in-react/ https://blog.logrocket.com/virtual-scrolling-core-principles...

crazygringo 4y ago
I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event, it would just determine the proportional position, and then display the relevent user elements. So I understand why this would allow you to skip this "hack", but at the same time I kinda feel like absurdly large dimensions are not something reasonable to expect a browser to support, because the browser has to implement a limit at some point. So it definitely feels reasonable to set a limit somewhere moderately beyond wherever you think the longest infinite-scroll-search-results page would produce from somebody actually scrolling for a couple of hours. E.g. maybe a kilometer long, but not 100 or 10,000 kilometers long. (By my calculations, 17,895,697 px at 96 ppi = 4.73 km, which seems pretty decent.)
- samwillis 4y ago
  > I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event Moving things, even with "transform: translate()", during an "onscroll" event has really bad performance and will always show some level of lag. Using the massively optimised bowser scrolling gives a much smoother user experience. What you do with the virtualised scrolling is limit the number of DOM nodes, and where possible recycle them during the scroll. But they are "absolutely" positioned within the scrolling area. So yes, you could potentially go taller by manually moving elements within an arbitrarily large scroll view, the ux will be frankly quite crap.
  - crazygringo 4y ago
    But for virtualized scrolling, the content you're scrolling to doesn't even exist before you scroll to it. There is no moving of things, so I don't understand what you're saying.
    - samwillis 4y ago
      If the height of the scroll area doesn't equal the height of an item X the number of items, you will have to change the offset position of each element within the scroll area on each scroll event. That will lag behind the scroll. To put it another way, if the total height of all items is greater than the height of scroll view, as you scroll from top to bottom the items need to move through the scroll view faster than than the scrolling element. To do that the items need to be moved on each "onscroll" event, even if you only drawing the small fraction of them that are currently visible.
      - crazygringo 4y ago
        Sure but there's no way around that. That's the whole point of virtualized scrolling. With virtual scrolling there's always going to be a lag in displaying. But it's also infinitesimal so it's fine. Also if you're just scrolling by tiny amounts (with trackpad or scroll wheel) then the virtualization doesn't matter, you just add new rows as needed while leaving everything in place. It won't precisely line up with the scroll bar position but the difference will be infinitesimally small, and then you can fix it once scrolling ends.
tsian2 4y ago
You can work around this issue by creating a bit of separation between the height of your items and the heights used in CSS. At these heights the scroll thumb is already reduced to it's minimum height, so as long as you make sure that scrolling jumps to that right point in the data you can "borrow" from the CSS height to stop it going over the maximum.
phpnode 4y ago
The solution is to use a virtualised scrollbar as well, so you have a div whose only purpose is to show a scroll bar, and then when that scrolls you scale the scrollTop proportionally. E.g. dragging the scroll bar by 1 pixel might equate to moving the grid by 20 items, but this is fine because in grids of that size it's impossible to precisely scroll using a scroll bar anyway. Scrolling via the scroll wheel is unaffected so the user doesn't notice.

crazygringo 4y ago

I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event, it would just determine the proportional position, and then display the relevent user elements. So I understand why this would allow you to skip this "hack", but at the same time I kinda feel like absurdly large dimensions are not something reasonable to expect a browser to support, because the browser has to implement a limit at some point. So it definitely feels reasonable to set a limit somewhere moderately beyond wherever you think the longest infinite-scroll-search-results page would produce from somebody actually scrolling for a couple of hours. E.g. maybe a kilometer long, but not 100 or 10,000 kilometers long. (By my calculations, 17,895,697 px at 96 ppi = 4.73 km, which seems pretty decent.)

samwillis 4y ago
> I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event Moving things, even with "transform: translate()", during an "onscroll" event has really bad performance and will always show some level of lag. Using the massively optimised bowser scrolling gives a much smoother user experience. What you do with the virtualised scrolling is limit the number of DOM nodes, and where possible recycle them during the scroll. But they are "absolutely" positioned within the scrolling area. So yes, you could potentially go taller by manually moving elements within an arbitrarily large scroll view, the ux will be frankly quite crap.
- crazygringo 4y ago
  But for virtualized scrolling, the content you're scrolling to doesn't even exist before you scroll to it. There is no moving of things, so I don't understand what you're saying.
  - samwillis 4y ago
    If the height of the scroll area doesn't equal the height of an item X the number of items, you will have to change the offset position of each element within the scroll area on each scroll event. That will lag behind the scroll. To put it another way, if the total height of all items is greater than the height of scroll view, as you scroll from top to bottom the items need to move through the scroll view faster than than the scrolling element. To do that the items need to be moved on each "onscroll" event, even if you only drawing the small fraction of them that are currently visible.
    - crazygringo 4y ago
      Sure but there's no way around that. That's the whole point of virtualized scrolling. With virtual scrolling there's always going to be a lag in displaying. But it's also infinitesimal so it's fine. Also if you're just scrolling by tiny amounts (with trackpad or scroll wheel) then the virtualization doesn't matter, you just add new rows as needed while leaving everything in place. It won't precisely line up with the scroll bar position but the difference will be infinitesimally small, and then you can fix it once scrolling ends.

tsian2 4y ago

You can work around this issue by creating a bit of separation between the height of your items and the heights used in CSS. At these heights the scroll thumb is already reduced to it's minimum height, so as long as you make sure that scrolling jumps to that right point in the data you can "borrow" from the CSS height to stop it going over the maximum.

phpnode 4y ago

The solution is to use a virtualised scrollbar as well, so you have a div whose only purpose is to show a scroll bar, and then when that scrolls you scale the scrollTop proportionally. E.g. dragging the scroll bar by 1 pixel might equate to moving the grid by 20 items, but this is fine because in grids of that size it's impossible to precisely scroll using a scroll bar anyway. Scrolling via the scroll wheel is unaffected so the user doesn't notice.