Cool and all, but... It's stuff like scroll analytics that keep NoScript in my list of must-have addons. That kind of stuff is just super creepy in a working-for-the-feds-in-snow-crash kind of way.
Not too bad. On the sticky elements example, if I furiously flick my scroll wheel downward, there is a noticeable but tiny delay for the section menu to "catch up" at the top of the screen. The infinite scroll example seems fine, as does the analytics example. Is there really any way to get faster performance in the first example other than just giving the section menu div position:fixed (which doesn't exactly do the same thing)?
Plugin author here, I can help clarify that. The scrolling is throttled so that all the checks aren't run with every single scroll event, as that would choke everything. So the small delay you see there is some 0-100 millisecond value while it hasn't triggered the event yet.
You can change the throttle by setting $.waypoints.settings.scrollThrottle = 50, or whatever number you like, to try to reduce flickers in cases like these. Just be aware its a balance you'll be striking with executing more scroll checks. But all the selectors and offset values are cached so the performance should still hold up should you choose to lower this value.
I love what you did with this and i will definitely play around with it. This functionality should really be built into the browser in my opinion. I was thinking, for performance reasons, did you try ditching the $(window).scroll and go with this? http://jsbin.com/eciwu4/edit
I very much disagree. It's an awesome way to capture the reader. I love it myself, not needed reloads, hunting for 'next' buttons, ... Yes you lose the relative position on the page indicator from the scroll bar, but it's irrelevant by the time you get to the bottom of the page anyway.
If the content is not truly infinite (#comments known?), just very large, you could solve the scrollbar issue by giving the page the right vertical size (or an estimation), but only populating the HTML if the user scrolls somewhere.
You'd use AJAX to load the elements, so it doesn't show as loading. And you make sure the user never sees the empty space, given normal scrolling speed, by loading the area around the visible screen. Certainly not worse than extending the page when the user reaches the bottom, as some sites do.
Useful idea, although the implementation makes Safari stutter on a CoreDuo MacBook. I didn't check the internals, but I have a feeling that some value checks would benefit from caching.
Either way, I wouldn't deploy this just yet. But I also wouldn't deploy a PNG background that's position: fixed, because I remember it crippling old versions of Firefox on Windows..
I guess it depends, but us users with slow computers avoid websites that point out the fact that we haven't upgraded for 4 years.. I think the web is most definitely the one place where you can't presume everyone is on par with Moore's law. You just can't increase performance requirements according to your workstation (at least not on the client-side).
Remember any leet Flash websites from 2001 (besides 2advanced, err) where the stop-motion effect would reveal your CPU's inferiority to the developers machine? Exactly, me neither (there were a lot of them though).
I hope the plugin takes off, but it won't happen until it performs. Making websites slow on old computers is much like making type too small for the visually impaired.
The elements and everything used during the scroll checks is in fact cached (which you'll be able to verify by looking at those internals you mention) and throttled per my comment below. As another commenter pointed out, the project page itself is full of drop shadows, text shadows, and css3 gradients, and opacity. Those are probably slowing you down way more than the plugin. Do you see the same performance problem from the relatively unstyled examples?
Mobile Safari parses websites as a big canvas and then pretends the screen is a window through which you're looking at the canvas. What you think of as scrolling, the browser thinks of as moving the canvas around (or the window depending on point of view).
Because of that, no scroll events ever get fired. Even :fixed doesn't behave as expected.
Calling .waypoint with no parameters will register the elements as waypoints using the default options. The elements will fire the waypoint.reached event, but calling it in this way does not bind any handler to the event. You can bind to the event yourself, as with any other event, like so:
someElements.bind('waypoint.reached', function(event, direction) {
// make it rain
});
Calling .waypoint with a function is just a shortcut for that.
I especially appreciated how, when going from the top of the page down to the bottom, the middle tab would show the down-state briefly, while the browser scrolls to the bottom.
