You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What's expected behavior when scroll snap is enabled and the user tries to scroll past the last snap position? Example: https://codepen.io/anon/pen/orOmeP. I'm asking because:
WebKit (Mac Safari, iOS any) will scroll to the end, leaving nothing visible in the viewport.
Blink (desktop Chrome) will refuse to scroll past the last visible element.
Which is correct? Or is this behavior currently unspecified?
FWIW, the current WebKit behavior causes a race condition that breaks current "virtual scrolling" implementations like Facebook's react-window that use JavaScript to JIT add/move absolutely-positioned elements in an otherwise-empty, very long container to simulate scrolling through a long list. Safari will scroll to the end of the content before the virtual-scrolling script has a chance to move elements to the user's new scroll position. Desktop Chrome doesn't have this problem.
If this behavior isn't specified today, then I'd suggest adopting the Chrome behavior as default in the standard. If it is specified, then is there any standardized way for infinite-scroll implementations to get the Chrome behavior?
The text was updated successfully, but these errors were encountered:
IMHO the start/end scrolling boundaries of a scroll container should implicitly create snap boundaries so that users can scroll back to the same position/boundary a scroll container originally loads in against. In short, I support webkits implementation.
Also, I’d suggest changing the title of this filing from referencing the “last visible element” to something regarding “past/before snap aligning elements” that aren’t at the scroll containers boundaries?
What's expected behavior when scroll snap is enabled and the user tries to scroll past the last snap position? Example: https://codepen.io/anon/pen/orOmeP. I'm asking because:
Which is correct? Or is this behavior currently unspecified?
FWIW, the current WebKit behavior causes a race condition that breaks current "virtual scrolling" implementations like Facebook's react-window that use JavaScript to JIT add/move absolutely-positioned elements in an otherwise-empty, very long container to simulate scrolling through a long list. Safari will scroll to the end of the content before the virtual-scrolling script has a chance to move elements to the user's new scroll position. Desktop Chrome doesn't have this problem.
If this behavior isn't specified today, then I'd suggest adopting the Chrome behavior as default in the standard. If it is specified, then is there any standardized way for infinite-scroll implementations to get the Chrome behavior?
The text was updated successfully, but these errors were encountered: