- From: Andy Earnshaw via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Dec 2023 12:52:40 +0000
- To: public-houdini-archive@w3.org
I really appreciate the candid response, Rick. I completely understand the point of view, it's important to put the needs of the many before the few. That being said, for me, scrolling is a recurring, frustrating problem that I don't think can be solved by high-level APIs. 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 ([and others](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, which browser vendors tell me they cannot resolve: [Maximum element size is too restrictive for virtual scrolling (crbug)](https://bugs.chromium.org/p/chromium/issues/detail?id=932109) [Maximum element size is too restrictive for virtual scrolling (Bugzilla)](https://bugzilla.mozilla.org/show_bug.cgi?id=1527883) I also never really got any traction [proposing](https://github.com/WICG/webcomponents/issues/791) a standards-based solution. It's a problem that can be worked around with a poorer user experience or highly complex custom scrolling implementations, but the low-level nature of the problem impacts use of any high-level APIs, especially CSS-based ones. Solving this problem at the standards level would go a long way towards reducing a lot of hacky code in a couple of components. With regards to scroll speed "warping", I need to directly manipulate the delta by which a user has scrolled and increase it or decrease it accordingly. The scrollbar would actually move slower at this point. It's a very specific use case and I don't see it being applicable in many situations, we're talking more like the 0.001% which is why I'd be excited by the prospect of a low-level API. That being said, what I'm working on right now is like a custom layout based on scroll position as well as scroll delta. It's very complex, and I need for the implementation to be easy to understand and low risk of edge cases. Using high-level APIs and workarounds amps up the complexity and makes it feel like a bunch of messy hacks to achieve a flawed solution, to the point where you trading one poor user experience for another. Ultimately, any solution I come up with ties scrolling back to the main thread and means I have to work really hard to keep rendering performance the main priority, which is why something like a worklet would be ideal. Again, I really appreciate the way you responded. I understand that these problems are not a priority for the Chrome team, it's likely true of other browser vendors also. Given that it's been 5 years since I originally tried to do something about the maximum element/scroll sizes, and 8 years since your draft proposal for scroll customisation, I may have to accept the fact that it's never going to happen! -- GitHub Notification of comment by andyearnshaw Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1118#issuecomment-1855797500 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 December 2023 12:52:43 UTC