- From: Justin Grant via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 Jul 2019 07:11:07 +0000
- To: public-css-archive@w3.org
Hi @jonjohnjohnson - Thanks for quick reply! Other than the priority of virtual scrolling, I suspect that we're pretty much in agreement on most points. Here's some responses and notes, let me know what you think. > I feel as though you don’t realize that scroll containers load in on the “scrollmin” position in the first place? Nope, I understand this. Every time I have to write code to set a non-zero scroll position on page load, I'm reminded of the default. ;-) > So what’s a scenario you can imagine where the initial scroll position should not be reachable after scrolling, even in what I consider the uncommon case of virtual scrolling? I don't know any case, including virtual scrolling, where a developer would deliberately want to make the initial position unreachable for the user. In a virtual list, users *can* scroll back to the initial position. The problem is a race condition: WebKit will scroll all the way back to the beginning or end of the list any time you flick/momentum-scroll because, at the time the user flicks, the list is mostly empty other than a few items under and around the scrollport. For example, imagine a user is currently viewing the 20,000th item in a virtual list and they want to go back 20 items. So they "flick right" hard enough to momentum-scroll for 20 items' width. But in the DOM there are currently only 2 items to the left of the scrollport, which means that a 20-item-width scroll will snap to the next snap point: scrollmin. Then the content starts scrolling in a blur for a few seconds, with display flashing as the virtual scrolling script madly tries to add new elements in front of the scroll position. Finally, the user ends up at the first item. Instead of scrolling 20 items, it scrolled 20,000. On blink, this works fine except momentum scroll is relatively slow and high-friction unless you add a lot more buffer items around the scrollport. > what I consider the uncommon case of virtual scrolling I don't have any stats on runtime usage, but here's a few data points about usage from the developer side. What level of developer usage do you think qualifies as not-uncommon? * The most popular react virtual scrolling library is [react-virtualized](https://www.npmjs.com/package/react-virtualized) with 390K weekly downloads and 16K GitHub stars. Its faster/smaller successor [react-window](https://www.npmjs.com/package/react-window) has 5500 stars and 84K downloads/week. There are a bunch of others too. * For Angular, there's a standalone [ngx-virtual-scroller](https://www.npmjs.com/package/ngx-virtual-scroller) with 10K downloads/week and 600 stars, but there's also other Angular virtual scrolling solutions built into larger libraries like https://material.angular.io/cdk/scrolling/overview * For Vue, there's [vue-virtual-scroller](https://www.npmjs.com/package/vue-virtual-scroller) with 10K downloads/week and ~2700 stars. Plus a few others. * For plain JS or JQuery, [Clusterize.js](https://github.com/NeXTs/Clusterize.js) has 6,000+ stars. There are other plain-JS solutions too. Every major JS framework has several popular implementations of virtual scrolling because it's usually the only performant and easy-to-implement way to display long lists that are scrollable. We may not hear much about this usage because much of it is in "enterprisey" reporting or line-of-business apps. But it's fairly common, esp. in newer B2B/SaaS and IT tools that frequently have a need to show scrollable lists and reports with 1000+ rows. > You refer to “empty space” but there can be content in the “space” that just hasn’t declared a choosable/reachable snap alignment based upon the size of the snapport, content, and aligned edge? Yep, understood. Was using "empty space" as a shorthand for something like "no reachable snap-aligned elements" because I was assuming that "no elements" would be the most common reason. Do you think the "no reachable snap-aligned elements near scrollmin/scrollmax" case is a common, intended case? Or is it likely to be a developer error like forgetting to snap-align some child elements? > Have you scrolled the original posts test case? Yep! I agree 100% with you that that test case is confusing UX on Chrome. I'm not opposed a solution that makes that case better, as long as that solution doesn't break virtual scrolling. While we're talking test cases, have you scrolled the top list on https://codesandbox.io/s/happy-architecture-m7pn5 on Safari? Let me know if you can think of another way to prevent the awful UX that happens when you flick/momentum-scroll that list on Safari. > I don’t think you’re realizing that the load in scroll position is “escaped” from what you propose, on top of being hostile towards users. Nope, I get it. It's weird. I suspect it's uncommon, but it's still weird to be unable to return home. I'd definitely support a solution that fixes this case as long as it won't break virtual scrolling. BTW, one other nice thing about the blink behavior is that achieving the webkit behavior is trivially easy for a developer or designer. On blink, to enable webkit-like snapping at scrollmin/scrollmax, simply put a snap-aligned element at scrollmin/scrollmax. No script required. For the reverse (preventing webkit from snapping at scrollmin/scrollmax) the only option, as far as I know, is to write a Javascript replacement for CSS scroll snapping. This is orders of magnitude harder... and hurts performance and UX too. -- GitHub Notification of comment by justingrant Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-511295421 using your GitHub account
Received on Monday, 15 July 2019 07:11:08 UTC