I faced the same annoyances :( infinitescroll is nice and dandy but it is really a pain in the posterior.
Glad to know I'm not alone...
;)Which one..?
I couldn't get a fine and stable code for scrolling events, yes jQuery has .scroll() and I can get if the user has reached the bottom of a page, however, it was very unstable (if the user stays at the bottom the event gets fire constantly) so I decided to use a "load more" button.
Yes, it's better for accessibility. Although, as you may have noticed, Wedge does it differently: it only triggers on mouse wheels, and only starts counting mouse wheels after you reach the end of the page. It was a deliberate decision, to ensure that the user actually wants to see the next page.
I must admit, I'm a mouse wheel freak... I tend to roll it everywhere, including at the end of a page, so it was a no-brainer for me. The counterpart, though, is that I can't decide whether to use the system to just load the next page the 'regular' way, because the current solution at least allows me to keep reading the last post in the page, even if I'm wheeling a bit too much.
Another issue was handling all the HTML, I had 2 options, sent the entire data plus HTML as a json object or just send the pure data and have all the HTML either created on-the-fly or as an empty shell on the template itself, I decided to just sent the already constructed HTML as a json object and then just use .append() on an empty <ul> created on-the-fly by jQuery.
Did your data have any events attached to them..?
I didn't want to have multiple template structures so I took the message HTML, isolated it on a single function with all the data (content, poster, time, etc) passed as a param and thats the only template I use for every place where I show a message, it is a little hackish because in the same function I can either return the structured HTML or just print it, depending on where exactly I'm using that template function, my solution was to use a var and at the end simple decide what to do, return it or print it, not nice but it works.
At this point, I'd be glad to have an ugly solution that just ensures developers can freely work around this infinite scrolling thing...
:-/I'm trying to figure out a 'different way', but it's hard. Something like, take all functions that knowingly modify messages (layout, contents...), and have them declare themselves to a special hook that will call them again when new posts are inserted. But I need to figure out a clean way to do that. And I don't even know if it's viable.
Either way, it probably won't be ready for v1.0... In fact, I'm likely to keep things as they are for now, because it 'mostly works', and I'll just fix my existing broken code (i.e. duplicate HTML.) I think that the face value of having this nice infinite scrolling effect is important for Wedge to gain some momentum among the SMF community, and if removed later and replaced with a plugin, it'll have less visibility and I'll be sad about it. (I DID spend a lot of time on this...)
I also faced the duplicate DOM elements, in my case it wasn't that much of an issue since I don't handle that many features and options, my solution was handling all JS events using jQuery(document).on() to differentiate between events I use the ID in the ID attribute so:
That's a good thing, but it's still something that should be kept to a minimum or to very specific events like the one in your example, because it does mean all events of the same type will bubble up the DOM, be caught by jQuery, which will determine if it was in the 'domain' it was watching, etc... Heck, I'm not exactly sure why the jQuery team replaced .live() with that. Maybe they wanted to make it harder to use the function, and thus encourage dropping it..?
But I recon, the amount of DOM elements I manage is extremely low and this approach wouldn't work on handling forum messages.
Oh, it might work, after all it's 2013, not 2004. Of course, IE6 won't like this...
:P But it's only a matter of months before I definitely drop IE6 support anyway. Whatever, eh...
