This will be really awesome. For anyone who hasn't tried to implement a Sticky element before, it's actually not as trivial as you might think. (And when I was looking for an existing implementation, they didn't support the "constrain" effect that is explained in the video.
To do it correctly, you need to track the up to 4 different element positions.
You've got your actual sticky element, then you've got the parent of the element to ensure it's within the view port. Then you've got the scroll container as well. Plus, you might have a constrain/target node, to ensure that the sticky element doesn't extend passed an artificial bounding box.
Overall, doing all of these domGeometry/position calculations on each window.onscroll event leads to extremely inefficient JS. I ended up removing the Sticky altogether because on iOS it would basically make my application unusable.
Here was my implementation[1]. It was considerably harder to created than I expected it would be... coding advice/tips welcome.
My two cents. You'll never be able to match the scroll smoothly listening for scroll events. Use requestAnimationFrame and listen for changes in window.scrollTop.
Not exactly poll. Use scroll events to start your polling; after the second time your loop function doesn't find a change in the scrollTop, stop requesting frames.
Even without this guard, with just the `old !== getScrollTop()` it doesn't eat so much CPU neither.
Amen to it being harder to _get right_ than first appears...
I've been working on a floating/sticky scroll solution over the last couple of days and decided to go with fixed positioning to try and lessen the CPU load. Dealing with all the edge cases and trying to keep the code as sane as possible has been a complete bitch. Off loading all that to the browser would be a godsend.
I believe the problem with iOS (unless my info is outdated) is that it doesn't listen to the scroll event until it's completed. so sticky stuff won't move until the user has finished scrolling and lifted their finger from the screen.
I ran into that problem with a project not too long ago. It wasn't for something sticky though; a modal with video would dock itself to the bottom of the page on scroll to allow for content viewing but having the modal still visible.
On iPads that docking wouldn't happen until after the scroll had completed instead of at the start of the scroll. I'm not sure if this happens on the latest iOS versions or not though. But it was fun explaining to project managers what was going on during QA.
Wouldn't that bind the functionality to user interaction beyond just scrolling?
Analytics shows us that this minor issue with iPads is of little concern. But at least I now have a suggestion for a solution if someone decides it's a big enough deal. Thanks for the tip.
Sort of. If you use an overflow:scroll element it does fire during scrolling. While the user's finger is down. You get no events for the momentum after that (which, irritatingly, I'm pretty sure is to stop people reverse engineering it) until it finally stops.
I am a both sad and happy that it may be obsolete soon. Maybe I can add feature detection for this and short-circuit 1000 lines of logic if sticky position exists.
To do it correctly, you need to track the up to 4 different element positions.
You've got your actual sticky element, then you've got the parent of the element to ensure it's within the view port. Then you've got the scroll container as well. Plus, you might have a constrain/target node, to ensure that the sticky element doesn't extend passed an artificial bounding box.
Overall, doing all of these domGeometry/position calculations on each window.onscroll event leads to extremely inefficient JS. I ended up removing the Sticky altogether because on iOS it would basically make my application unusable.
Here was my implementation[1]. It was considerably harder to created than I expected it would be... coding advice/tips welcome.
[1] : https://gist.github.com/Kalyse/6534936 (My personal Sticky implementation using Dojo).