- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Dec 2022 23:01:17 +0000
- To: public-css-archive@w3.org
Giving the use cases some more thought, this issue seems to be sufficiently different from #4264 to discuss it separately. And I have some notes and questions: Is avoiding scroll anchoring suppressions actually necessary? @emilio as I understand this request, you want to introduce a way to _always_ use scroll anchoring and disregard any [suppression window](https://drafts.csswg.org/css-scroll-anchoring/#suppression-windows), correct? From the discussions, it looks like the main issue you want to fight with this change is jumping on infinitely scrolling pages like facebook. Though reading the spec. text it seems the suppression window and [suppression triggers](https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers) where introduced exactly for that use case. But I don't know enough about the issue regarding scroll event listeners, so maybe I am misunderstanding something here. Maybe it would help to outline the use case for avoiding scroll anchoring suppressions and provide an simple test case where the current algorithm fails. And depending on the use case, it might not be necessary to introduce a new value but improve the [anchor node selection algorithm](https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection) instead. If it turns out that we somehow require further control over avoiding anchoring suppressions, we should also consider whether it makes sense to add it to `overflow-anchor` or rather add a way to control this on the scroll container itself instead. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7745#issuecomment-1347459813 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 December 2022 23:01:19 UTC