Simple test case: https://codepen.io/GreenSock/pen/VwxxwWm?editors=0010 Scroll on any iOS device relatively quickly up and down. Notice the blue bar bounces around like crazy rather than staying "stuck". The scroll position seems to be incorrectly reported or rendering is happening out-of-sync. Challenge: can you please recommend a way to keep the blue bar "stuck" using transforms? I can't use something like position: fixed because the container may have a transform applied. sticky isn't an option either. I need a way to get the correct scroll position and apply it at the correct time to make that element appear frozen while scrolling its container. Help?! I've reached out directly to the Safari team at least 5 times over the past few months and never receive an answer, so I'm posting a bug report here. I have no idea if these are related to this issue, but here are several other reduced test cases showing various scroll-related bugs/inconsistencies in iOS Safari: - https://codepen.io/GreenSock/pen/XWajYwG/16c435b12ef09c38125204818e7b45fc - https://codepen.io/GreenSock/pen/ExbrPNa/087cef197dc35445a0951e8935c41503 - https://codepen.io/GreenSock/pen/JjOxYpQ/3dd65ccec5a60f1d862c355d84d14562
It's currently not possible to position an element in JavaScript in a way that is frame-accurate with user scrolling. Scrolling on iOS is always asynchronous.
Dang! Okay, "currently not possible..." does that mean that may change sometime soon? [fingers crossed] And can you think of any out-of-the-box strategies to somehow make this work?
The only way would be to use position:fixed or position:sticky. Can you hoist your fixed thing outside the transformed ancestor?
Unfortunately, no, that isn't possible. We don't have control over the markup/structure. There aren't any tricks to getting scroll to be synchronous? I attempted to preventDefault() on touchmove events and handle the scrolling via JavaScript which should totally work in theory, but there's a nasty bug in iOS Safari since 2018 (from what I can tell) that makes it impossible because the event.clientY/X are incorrectly reported, as illustrated in one of my demos provided: https://codepen.io/GreenSock/pen/ExbrPNa/087cef197dc35445a0951e8935c41503 That bug report is here: https://bugs.webkit.org/show_bug.cgi?id=181954 I tried bumping it months ago and got no answer. So I have no way of figuring out where the user's finger actually is in the viewport (reliably) when scroll is involved. Or am I missing something?
<rdar://problem/101055653>