11–20 of 27 posts
cool use of waypoint scrolling to mimic tab traversal on the homepage.
This didn't work on my iPhone. I wish it had.
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.
Is it just me or does this feel really slow?
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…
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.
Earlier quoted context omitted.
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…
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…
Is it just me or does this feel really slow?
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…
If I notice it, then by definition it is too bad.
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.
Earlier quoted context omitted.
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…
Reminds me of this, I guess you read it already: http://ejohn.org/blog/learning-from-twitter/
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…
Earlier quoted context omitted.
Fits right in with jquery. Then in the next version they can announce it's 2000% faster.
First you make it work, then you make it perform well. What, you were expecting the first code they wrote to be perfect?