
JQuery Waypoints - execute a function whenever you scroll to an element - moeffju
http://imakewebthings.github.com/jquery-waypoints/
======
joebananas
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.

------
chrisbroadfoot
Is it just me or does this feel _really_ slow?

~~~
baddox
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)?

~~~
imakewebthings
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.

~~~
patrickaljord
Reminds me of this, I guess you read it already:

<http://ejohn.org/blog/learning-from-twitter/>

~~~
imakewebthings
Based the throttling on that exact post.

------
some1else
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.

~~~
imakewebthings
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?

------
skilesare
This didn't work on my iPhone. I wish it had.

~~~
Swizec
That's because you weren't scrolling.

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.

------
shib71
Nicely modular functionality. Would be even better if the events were
implemented as actual jQuery events.

~~~
moeffju
They are:

 _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.

------
sramam
cool use of waypoint scrolling to mimic tab traversal on the homepage.

~~~
tjarratt
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.

