- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Dec 2023 15:45:51 +0000
- To: public-houdini-archive@w3.org
> I regularly work on tables and lists that are completely custom views on customer data. They can, potentially, have millions of rows and/or columns. 95% of customers probably have less than a thousand rows and less than 30 columns. In reality for me, I can't ignore the 5% because they are paying the most! So, I (https://github.com/w3c/csswg-drafts/issues/3397#issuecomment-453851055, including [the Microsoft Excel team](https://bugs.chromium.org/p/chromium/issues/detail?id=932109#c24)) run into issues like maximum scrolling sizes While a bit of a hack, for use cases like this you could use a large scroller with a scroll listener and if the scrolled distance is a small amount (e.g. page-down or less) you would track the relative change and update the scroll position to be the absolute position. And if the scroll is a large amount (e.g. scrollbar drag / home / end keys) use the overall absolute position as the position to seek to. Here's the example from [the crbug](https://bugs.chromium.org/p/chromium/issues/detail?id=932109) updated to use this strategy: https://jsfiddle.net/flackr/gw132dev/ Ideally a browser primitive would let the developer provide the DOM around the current scroll position and the browser could even scroll that content quickly without needing it to be drawn frame by frame by the developer, and only when you scroll far we would need the developer to provide the new content. We could also use similar strategies to my demo to allow for larger ranges than are normally scrollable. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1118#issuecomment-1858087563 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 December 2023 15:45:52 UTC