Links

Lists

Latest Updates

Ruby On Rails List
Python list
Advanced Java
The JavaScript List
Apache Users
Full Disclosure
Linux Security

Search the archives!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Javascript] Controlling Page Scroll Position


  • From: fairwinds at eastlink.ca (David Pratt)
  • Subject: [Javascript] Controlling Page Scroll Position
  • Date: Wed Jun 29 15:08:04 2005

Hi Paul.  This is really great and very helpful.  I need a bit of time 
to see if I can put it all together and see if I can get this to work.

On the last part.  The pages will be pretty much the same height and I 
believe that looking at any more than 20 rows at a time is a bit much.  
I also want to keep my queries snappy.  For the most part the tables I 
want to stay in the view are about 3/4 down the page and the pages are 
about twice the length of the screen 1024 resolution.

I was thinking the other thing I could do is just to put an id in the 
heading above the table and pass a bookmark into the href so it goes 
directly to the place on the page. A no javascript solution that would 
take user to the place on page with no muss no fuss.

I have just read Hassan's response and I am thinking if you navigate to 
a page using the pager (other than first page), perhaps he is right and 
I should just turn off the instructions and pass a variable to control 
this on my template.  On the page the user navigates to I could instead 
have a link  to click to refresh the page to bring them back.  You 
folks have really given me something to consider.  I appreciate the 
wisdom :-)

Regards,
David

On Wednesday, June 29, 2005, at 03:55 PM, Paul Novitski wrote:

> At 11:13 AM 6/29/2005, David Pratt wrote:
>> So first problem is that an id would not work since I have at least 7 
>> links that cannot share the same id.
>
> Well, sure -- you could either give each link a unique id or you could 
> just identify their common parent.
>
> Because you have several items in the same group, all you need to do 
> in your script is identify their container, e.g.:
>
>         var oBox = document.getElementById("pagenav");
>         var aEls = oBox.getElementsByTagName("A");
>
>         for (var iEl=0; iEl < aEls.length; iEl++)
>         {
>                 aEls[iEl].onclick = doSomething;
>         }
>
> ...which sets aEls equal to the collection (object array) of anchor 
> tags contained within "pagenav," then iterates through them.
>
>
>> The first, previous, last and next   are enclosed in a span tag so I 
>> have more control over the css and have anchor tags only when they 
>> are active.
>
> Spans are fine, although they're semantically meaningless.  You might 
> want to consider using an unordered list, which your list of page 
> links arguably is, and which (like spans) you can style with CSS into 
> either a vertical or horizontal series of items depending on how you 
> skin your application in future.
>
>
>> The five pages use either page_plain or page_selected  (only one 
>> would have page_selected) at a time to show the active page.
>
> If you have only two states possible then you only really need one 
> class:
>
> <ul id="pagenav">
>         <li><a href="#">previous</a></li>
>         <li><a href="#" class="page_selected">1</a></li>
>         <li><a href="#">2</a></li>
>         ...
> </ul>
>
> The container for your list of page links lets you unambiguously 
> identify all the items in the list (regardless of what markup tags 
> you're using), so you can style them all the same way (what is now 
> "page_plain"), then make an exception for "page_selected."
>
>         #pagenav a
>         {
>                 color: #000;
>         }
>         #pagenav a.page_selected
>         {
>                 color: #FFF;
>         }
>
>
>> For me even though it is the norm for page advance is to go to the 
>> top, I find it personally annoying when I am in a series of rows and 
>> want to advance to the next set page of rows without bouncing to the 
>> top where the same instructions exist and have to pull down to view 
>> my next series of results in the table.  I am thinking users may 
>> appreciate this and I would likely make it an optional behavior.
>
> I'm wondering where on the page you'd locate your page links.  If a 
> page is, say, four screenloads tall, will you have a new set of page 
> links every N rows?  How many is N?  Obviously the user won't be able 
> to scroll up or down to find the page-links! without breaking the 
> system.
>
> I'm wondering whether it wouldn't make more sense to give people 
> single-screen blocks of your data table, and let them "page" right, 
> left, up, and down to see adjacent blocks of data, in much the same 
> way that Excel lets you tile printouts of tables that don't fit on a 
> single page.  That way you wouldn't have to introduce the 
> auto-scrolling issue, you could generate the page links from 
> server-side, and your pages would work fine in browsers with 
> javascript disabled.  It's basically the same as you're doing now, 
> just tiling vertically as well as horizontally.  The only issue would 
> be coping with varying monitor dimensions, which you clearly need to 
> deal with now in order to calculate how many columns of data can fit 
> on the current screenload.
>
> Warm regards,
> Paul
>
>
>
> _______________________________________________
> Javascript mailing list
> Javascript@xxxxxxxxxx
> https://lists.LaTech.edu/mailman/listinfo/javascript
>