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
>
- Follow-Ups:
- [Javascript] Controlling Page Scroll Position
- From: Paul Novitski
- [Javascript] Controlling Page Scroll Position
- References:
- [Javascript] Controlling Page Scroll Position
- From: Paul Novitski
- [Javascript] Controlling Page Scroll Position
- Prev by Date: [Javascript] Regular Expression example
- Next by Date: [Javascript] Controlling Page Scroll Position
- Previous by thread: [Javascript] Controlling Page Scroll Position
- Next by thread: [Javascript] Controlling Page Scroll Position
- Index(es):