W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [cssom-view] Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions (#5677)

From: Cody Olsen via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Oct 2020 22:04:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-718235126-1603922654-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC