- From: Bruno Stasse via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Jun 2022 15:12:59 +0000
- To: public-css-archive@w3.org
Reposting my [comment](https://github.com/w3c/csswg-drafts/issues/6299#issuecomment-1138726367) here as it is directly related to the topic. --- If I may comment from a developer perspective on the effect of overscroll on JS APIs: Scroll position during overscroll or intersection observer used to detect overscroll in Safari is currently used for a variety of features and effects: custom pull-to-refresh, growing page title, growing hero image, revealing hidden elements with transitions or triggering animations elsewhere past a certain threshold, keeping parallax effects going during overscroll and not stopping abruptly, animating text features, etc. I have myself implemented such features, and have had to disable overscroll (with overscroll-behaviour: none) in Firefox on macOS because it wasn't detectable, which is a shame. Removing it from Safari would be likely to break a large number of websites/web apps and make all these features and effects impossible. A new dedicated "pull-to-refresh" API might help recreate some of these, but probably not all. Safari's overscroll behaviour is a translation that is in the continuity of the scroll, so it is quite natural that it is treated as such and reflected in all scroll related APIs. I would also expect it to work in combination with the upcoming Scroll-linked Animation CSS and JS APIs. It wouldn't make sense for a scroll-based animation to stop abruptly when reaching the end of the scroll container, while the content keeps moving during overscroll. I would argue that any visual change to elements, whether it is a translation (rubberbanding in Safari) or a transformation (stretching on Android) should be detectable and reflected in JS and CSS APIs. If an element can be moved, possibly over another one, or cut by an overflow, it needs to be known by developer code, or it might break. This is true for scroll positions, intersection observer, boundingClientRect, scroll-linked animations, etc. Even though these behaviours vary between platforms/browsers, wouldn't it be possible to write specifications for them, so that interactions with the different APIs are defined? This would allow to have interoperability between the browsers implementing them. Hoping that helps. -- GitHub Notification of comment by brunostasse Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4011#issuecomment-1144981856 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 June 2022 15:13:01 UTC