- From: Cody Olsen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Oct 2020 22:04:15 +0000
- To: public-css-archive@w3.org
>For `scrollIntoView()` extensions, I think it would be good to review what parts of https://github.com/stipsan/scroll-into-view-if-needed developers are using and should be in the web platform directly, and whether the API shape in this PR is the right one. Let me know if there's anything I can do 🙂 In my experience `scrollMode: "if-needed"` is often enough for most. Then we have the common use case where devs are confused/surprised when they experience `overflow: hidden` frames getting scrolled, common enough to warrant [adding a workaround](https://github.com/stipsan/compute-scroll-into-view#skipoverflowhiddenelements). The [`custom behavior`](https://github.com/stipsan/scroll-into-view-if-needed#function) API was added as an escape hatch for the other corner cases instead of bloating the API surface further. Since then a growing number of libraries prefer this pattern, as they want control over how the scrolling operations are performed: https://www.npmjs.com/browse/depended/compute-scroll-into-view It could be helpful to have a similar utility in the platform, allowing us to calculate what should scroll where, but let us handle the actual scrolling 🤔 -- GitHub Notification of comment by stipsan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5677#issuecomment-718235126 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 October 2020 22:04:17 UTC