Ryan, Yeah, was thinking about this again after my last posting. I really don't need or care about updating the secondary ads listing until after 'X' amount of time after the scroll has stopped. Only then do I need to trigger the function to collect the visible items. I see this as akin to capture on a live search input field. There is normally something like a 250ms delay on the keyup event. You don't want to trigger AJAX calls too early as it might kick off too many requests.
Thanks for the code. I'll take a look in a few. After more coffee. As for doing this on the server I don't think so. This scroller area will be in a sidebar and the height will be dynamically set the the height of the screen. Plus the ads will be mixed text and images. Some rows will contain both. So hard to tell the actual height before rendered. Paul On Nov 25, 2012, at 12:06 PM, Ryan Joy <[email protected]> wrote: > Hi Paul, > > Are you able to do any of ad placement calculations on the server? That would > allow you to place marker elements in the list and only calculate their > scrollTop, rather than the intensive height calculation on 5000 other > elements. > > Here is my “first cup of coffee” jsbin example: > http://jsbin.com/amepeh/3/edit > > I don’t think you’d want to iterate over the entire ads array on each scroll, > but this might help point you in another direction. > > Cheers, > -RYAN > > -Sent from my Surface. Develop an app for it! > http://rj.cx/app_in_30_days > > From: Paul Menard <[email protected]> > Sent: November 25, 2012 10:53 AM > To: [email protected] > Subject: Re: [Refresh Austin: 6744] jQuery determine visible row elements in > a scrollable div > > For anyone interested in a working concept https://gist.github.com/4144281 > > This contains a fair amount of debug output. Not needed on the final code. > > Probably not as elegant as some of the code others may produce but should be > a good start for my needs. Instead of the storing of the array I'll probably > just set a class on the visible row elements. Then I can select this via > some external code. So this bit of code will be just something to 'mark' the > visible elements. Working on adding the throttle plugin logic (had no idea > that existed) and turn this into a proper function. Thanks all for the > pointers. > > P- > > On Nov 24, 2012, at 12:20 PM, Rob Lifford <[email protected]> wrote: > > Hey Paul, do these internal row elements all share a common, fixed height, or > are those variable? If so, this is relatively straightforward—just bind to > the scroll event of the container (you'll usually want to throttle or > debounce any kind of scroll handler) and, based on its scrollTop property you > can figure out how many elements are scrolled out of view, and then how many > elements must be visible in the fixed height container. > > If they're all potentially different heights, it's probably a lot more > involved, so I figured it's worth it to ask first question first... > > RL > > > On Saturday, November 24, 2012 at 10:39 AM, Paul Menard wrote: > > Greetings all, > > Working on some ad logic for a client and can't seem to get my head around > it. Looking for some code suggestions. Here is the logic. > > On the page there will be a fixed height div container. This container will > be set to overflow so it will allow the internal elements to scroll. The > internal row elements will be anywhere from 1 to 5000 depending. Each row > element will have a unique element id. > > I need some JS (prefer jQuery) which will determine the ids of the visible > row elements. I don't really have working code. So nothing to share at the > moment. Just wondering if someone had done something like this before. > > The reason this is needed is when the user scroll there will be a secondary > div showing ads based on the visible elements. > > P- > > > -- > Our Web site: http://www.RefreshAustin.org/ > > You received this message because you are subscribed to the Google Groups > "Refresh Austin" group. > > [ Posting ] > To post to this group, send email to [email protected] > Job-related postings should follow http://tr.im/refreshaustinjobspolicy > We do not accept job posts from recruiters. > > [ Unsubscribe ] > To unsubscribe from this group, send email to > [email protected] > > [ More Info ] > For more options, visit this group at > http://groups.google.com/group/Refresh-Austin > > > -- > Our Web site: http://www.RefreshAustin.org/ > > You received this message because you are subscribed to the Google Groups > "Refresh Austin" group. > > [ Posting ] > To post to this group, send email to [email protected] > Job-related postings should follow http://tr.im/refreshaustinjobspolicy > We do not accept job posts from recruiters. > > [ Unsubscribe ] > To unsubscribe from this group, send email to > [email protected] > > [ More Info ] > For more options, visit this group at > http://groups.google.com/group/Refresh-Austin > > > -- > Our Web site: http://www.RefreshAustin.org/ > > You received this message because you are subscribed to the Google Groups > "Refresh Austin" group. > > [ Posting ] > To post to this group, send email to [email protected] > Job-related postings should follow http://tr.im/refreshaustinjobspolicy > We do not accept job posts from recruiters. > > [ Unsubscribe ] > To unsubscribe from this group, send email to > [email protected] > > [ More Info ] > For more options, visit this group at > http://groups.google.com/group/Refresh-Austin -- Our Web site: http://www.RefreshAustin.org/ You received this message because you are subscribed to the Google Groups "Refresh Austin" group. [ Posting ] To post to this group, send email to [email protected] Job-related postings should follow http://tr.im/refreshaustinjobspolicy We do not accept job posts from recruiters. [ Unsubscribe ] To unsubscribe from this group, send email to [email protected] [ More Info ] For more options, visit this group at http://groups.google.com/group/Refresh-Austin
