Thursday, June 5th, 2008

Implementing infinite scrolling with jQuery

Category: jQuery, Showcase

Umut Muhaddisoglu has implemented the infinite scrolling pattern that Wikia Search has in place this week.

There have been other implementations, but this is a clean one using jQuery, and works by:

  • When user scrolls down and hits the bottom a function is called
  • This function gets the last DIV ID of the datagrid
  • Send a query with this DIV ID
  • Return the results and add them to the end of the datagrid.

You can check out the demo on Umut’s DNS Pinger service by scrolling down. The parts of this demo are:

The HTML structure to build on:

  1. <div class="wrdLatest" id=9>content</div>
  2. <div class="wrdLatest" id=8>content</div>

The function to put a loading icon in, and then fill it out with new content:


  1. function lastPostFunc()
  2. {
  3.     $(’div#lastPostsLoader’).html(’<img src="bigLoader.gif"/>’);
  4.     $.post("scroll.asp?action=getLastPosts&lastID=" + $(".wrdLatest:last").attr("id"),    
  6.     function(data){
  7.         if (data != "") {
  8.         $(".wrdLatest:last").after(data);          
  9.         }
  10.         $(’div#lastPostsLoader’).empty();
  11.     });
  12. };

The scroll detection:


  1. $(window).scroll(function(){
  2.         if  ($(window).scrollTop() == $(document).height() - $(window).height()){
  3.            lastPostFunc();
  4.         }
  5. });

Posted by Dion Almaer at 10:21 am

3.7 rating from 96 votes


Comments feed TrackBack URI

One thing you might want to consider is that the value of an ID is not supposed to start with a number, according to the w3c. You can easily get around this issue by adding a prefix to the ID and then stripping it from the value in the script if you need the ID to act as some sort of index.

Comment by kswedberg — June 5, 2008

I definitely like this method. Some predictive fetch would be nice – when scrolling with the bar versus the mouse wheel it’s a little too jumpy (at least in Firefox 3)

Comment by matanlurey — June 5, 2008

Good idea, but could be improved on by starting the request at around 80-90% of your way down so the “lag” is less noticable.

Comment by Anonymouse — June 5, 2008

Regarding kswedberg’s comment, what does w3c have to do with how you want to define your ids?

Comment by rsumi — June 5, 2008

Thanks to Ajaxian for sharing my post.

The %80-%90 idea can be accomplished with pixels easily by updating this:

if ($(window).scrollTop() == $(document).height() – $(window).height()){


if ( ($(document).height() – $(window).height()) – $(window).scrollTop() == 100){

This way the auto-loading will start when you are 100px close to the bottom. This can also be translated into percentages too.

Comment by wrd — June 5, 2008


w3c’s standards for DOM nodes states that an ID of an element, like a variable name in most programming languages, cannot start with a number. Instead of id = "8", a more appropriate identifier would be id = "iscroll_8".

Another reason is the fact that DOM element’s are not name spaced, and if two or more scripts could want to create an “8” element they would collide. Instead they could each create their own prefix (namespace-ish) for their elements.

Comment by matanlurey — June 5, 2008

Yes, my implementation checked to see if there was less than 100px left to scroll before fetching the next recordset. User waits around much less this way. Also need to check if not enough records exist to reach 100px from bottom, in which case auto-fetch the next recordset immediately.

Comment by aheckmann — June 5, 2008

demo aint even working in opera .. as most of ‘advanced’ jQuery stuff. That lib is useless.

Comment by mefisto — June 5, 2008

Interesting and cool, ours is faster though ;)
Even though we even have “controls” inside of ours (try clicking the images)
That’s the problem with client-side Ajax libraries, even though jQuery in itself was Opera compliant the actual client-code on TOP of jQuery very seldom would be since very few developers have the time and resources to check their client code against Opera…
I think ours is mostly working in all browsers though, even though it’s just a BETA. If not I can guarantee you it’ll work when we go into release…

Comment by polterguy — June 6, 2008

i’d lust like to back up the comments about ud attributes not beginning with a number. just because lots of people do it doesn’t mean it’s right ;-)

Comment by Jamie — June 6, 2008

regarding IDs in X/HT/ML: let’s face it people, the w3c has f**d up more than one standard and is more than belated on others. specifically concerning ID rules, they have been so a**tight it defies description.

browsers are able to work with a much greater range of ids such as `84`, `foo[bar]`, and so on, all of which are forbidden according to the w3c. granted, it’s a bad IDea ;-) to write “, ¿but “? ¿¿can’t be so difficult to parse, no??

why does that matter? well simply because not being able to use meaningful IDs means you have to resort to rewriting tricks and/or arbitrary numbering. suppose you have a form that displays product details. it would be most natural to identify your form fields as, say, `product[12].name` or `product/12/name` or something. but not, that is forbidden. to escape that and keep validity, you can (a) use a scheme like `product_12_name` (which may accidentally collide with tablenames such as `product_tags`), invent a scheme that translates all forbidden characters to markup like, say, `_0020` (for a space) or (c) use nonce values like `x1122345` (that you somehow have to link, on the server and in the browser, with appropriate semantics). both ways sort of suck.

in the end, i’ve come to see it this way: (1) standards are good, but (2) rules are there to be obeyed, bent, or broken; (3) browsers are fine with a number of things that the w3c prohibits; (4) when i need something that just works in targetted browsers, but bends or breaks w3c rules, and there is no practical way to obey, i go for bend or break; (5) profit!.

* putting an “ in a XHTML 1.1 document is forbidden, so i resort to XHTML 1.0 (obeying)

* “ has never been accepted, so i either do it anyway (breaking) or inject it using jQuery (bending)

* custom attributes like `xxx` are SO practical and WORK that i just DO it (and clearly break the rules thereby).

similarly for IDs with forbidden characters in them.

Comment by loveencounterflow — June 6, 2008

ah i hate blogging systems that swallow HTMLish things instead of simply escaping them (and no way to preview and correct). SUCKS. trying it again:

…granted, it’s a bad idea to write out an ID using character entities, but `[div id=’42’]` can’t be so difficult to parse, no??

* putting an `iframe` in a XHTML 1.1 document is forbidden, so i resort to XHTML 1.0 (obeying)

* `[form autocomplete=’off’]` has never been accepted, so i either do it anyway (breaking) or inject it using jQuery (bending)

* custom attributes like `[p frobulation=’42’]xxx[/p]` are SO practical and WORK that i just DO it (and clearly break the rules thereby).

Comment by loveencounterflow — June 6, 2008

Sure, why don’t we ditch the whole standard and create some stupid proprietary BLOB system able to render “whatever” in “whatever”…
Or totally give a damn about everything that has to do with standards and cross system communication, what the heck ActiveX works in IE, right…?
Ohh yes, I totally forgot. It won’t have any insurance in regards to also functioning tomorrow, new browsers are likely to break on it and your site will probably be useless in less than two years on all existing browsers in the world… ;)
It’s kind of like; “Why don’t we build new railroad tracking dimensions, the ones with a width of xxx are far superior in regards to safety, security and energy consumption”…
Standards are there to OBEY by PERIOD! (If you can at least, and mostly you can, at least we have not yet met one problem with them.) And to break the standard on something as stupid as ID naming conventions is pure arrogance or ignorance! At least as long as you KNOW you are doing it…

Comment by polterguy — June 6, 2008

I agree with not using only the ID’s as the same content may be used somewhere else at the website and you may again need to use the IDs. Making them product_id or product_last_id will not only make them standards compliant but also much more unique.

I’ll update the code with div ids being not only numbers.


Comment by wrd — June 6, 2008

“Standards are there to OBEY by PERIOD!”

we are the borg! all your base are belong to us! comply!

but of course you are completely right that a deviation from conceived uniformity stands a certain risk of not being as universally applicable.

for the record, i think the web has greatly profited from the standards movement, and i’m happy to see a lot of vendor-specific crap of the past is on the way out. however, i do not expect browsers to balk on id=’234′ within the next two years, and, frankly, when i read the specs, i get the feeling the w3c got a tad overboard with concerns when they restricted IDs. after all, XML was designed to provide a common denominator for data exchange, so it is at least inconvenient that the strict rules for “something as stupid as ID naming conventions” make people waste time on circumventing those restrictions, instead of just copying their own IDs (eg from a database, where they are typically integer numbers or arbitrary strings) into the XML.

“It won’t have any insurance in regards to also functioning tomorrow”

i can’t think of anything with a guarantee into the future. also, your comparison with railroad construction is a little skewed. sure we do invent new systems all the while. “you can’t have an ID in XML that starts with a digit” is more like “you can’t offer paper towels in trains as that conflicts with established standards of international railroad traffic”. NOW COMPLY ALREADY!

Comment by loveencounterflow — June 6, 2008

@loveencounterflow (man you *really* need to change your nick ;)
Regarding the fact that the standard prevents IDs from starting with numbers is stupid, I completely agree with you. It is a really stupid rule. Though when it is there we really have no other alternative than to obey by it until there comes a new version of (X)HTML which might have the possibility to change it. The reason is since the “alternative” leads to a path we don’t won’t to go with “blink” tags, “layers” and “document.all[x]”…
When (yes *when*, we’re closing in on it ;) there is a truly standard compliant browser – if you follow the standard then your code WILL work on that browser. Probably also until “the end of time”. Just like there still exists systems that can parse morse-code today. If some bugger during the 1850s had invented his own “improved” version of morse-code then today that stuff would have looked like crap and be completely un-readable for the entire known universe today…
There are several others that tries to invent their own “new and improved crap” today for the web (no names mentioned)
The only thing we (members of the OPEN Web) can try to do is to fight back with standards…
That’s why I am so hard on my perception of standards. The stuff we do today must also work 100 years from now. The Egyptians built the pyramids to last for 65,000 years, the only route in SW that leads to the same kind of impressive results are standards…

Comment by polterguy — June 6, 2008

@polterguy “when it is there we really have no other alternative than to obey by it until there comes a new version of (X)HTML ” — well, i for one stopped believing that the w3c will any time soon publish updates to their standards like xhtml2, css3, and so on.

also standards don’t fall from heaven; they’re man-made, they’re agreements, conventions. when a body responsible for doing the standards has, like the w3c, failed to work as expected (css2 was made a recommendation in 1998 — css level3 is still under development as of _2008_!), guess what happens — people move on.

i am not the only one to suggest there are areas in web publishing where a “let’s obey the rules as far as possible, bend them where necessary, and break them where called for” attitude. i have to deliver web sites that work. a suggestion taken from an article on “Allow fragment identifiers to start with any ASCII character, not just a letter. Suddenly hundreds of millions of Blogger comment URLs become valid.” sounds reasonable to me.

ah, btw the oldest egyptian pyramids appear to date from around 2500 bc (give and take), which makes them 5k years old — hard to imagine the will survive 12 times as long into the future (your 65000 years), given their present delapidation. also, hard to imagine that in a 100 years from now people will still use css2. except, of course, for those that swear by the w3c. many already swear on them today.

Comment by loveencounterflow — June 6, 2008

@love…. (change your nick ;)
The Pyramids have been inspected in regards to how they are being worn out by weather and stuff like that and they are expected to last for yet another 60,000 years. In fact the only human made things which will outlast them are plutonium waste!
Standards typically lasts for 10 years before revised, look at C++, SQL and C. Most of them have ten years of delta before being revised and updated.
To break a standard due to being too lazy to add up a simple thing like “pr_” as prefix isn’t only ignorant and selfish, but also borderline to EVIL!
At least when you KNOW that you are breaking the standard. There might be other places where one “needs” to break the standard, but we’ve manages to get our samples 100% XHTML compliant, and I bet I could convince people that they were looking at Silverlight or Flash if I removed the chrome from the browser. Take a look yourself if you don’t believe me;
(PS! They’re not 100% XHTML compliant yet before we release the BETA 4 for Glory)
Now if we can do THAT without breaking standards, then surely you can create a blogging system, CMS system or mostly any other thing on this planet without having to “improve” standards…

Comment by polterguy — June 7, 2008

@polterguy, sorry to tell, but it looks like your website (ajaxwidgets) raises some warning concerning the… IDS…

line 12 column 1 – Warning: ID “__EVENTTARGET” uses XML ID syntax

An ID attribute does not conform with the HTML document type specification. ID tokens must begin with a letter, and may contain only letters, digits, hyphens, underscores, colons, and periods.

ID “_note-0” uses XML ID syntax
No Good : Note number zero.
Good : Note number zero.

Choose another name for the ID.

* SGML basic types:

Comment by hophophop — October 23, 2008

Nice one mate. I have also added the link to your post in my Ultimate collection of top jQuery tutorials, tips-tricks and techniques to improve performance. Have a check below:

Comment by shahriar — October 12, 2009

Leave a comment

You must be logged in to post a comment.