Scrollable tables

[Charles Belov]

I would like freeze panes on HTML tables that doesn't require extra scroll bars which only apply to the table itself.

That is, if a table extends beyond the browser window, the heading row "sticks" to the top edge of the browser window as you scroll down, until you run out of table, at which point it disappears off the page. And the first column "sticks" to the left edge of the browser window as you scroll right until you run out of table, at which point it disappears off the page.

I'm guessing this would require a combination of JavaScript and CSS.

I notice that all the "solutions" I see on the Web:

1) Require separate scroll bars for the table.
2) Don't allow the table to take advantage of the full browser window.
3) With few exceptions, don't work well cross-browser, and
4) Require fixed-width table columns

At this moment, I'm more concerned with tall tables than with wide ones, but I do have a few wide ones on my site as well.

Any alternate solutions?
Anyone

[MikeFoster]

Hi Charles,

I did a little experimenting with it.

[MikeFoster]

I've made quite a few updates to the experiment

[Charles Belov]

Way cool! Thank you very much for rising to the challenge.

On the PC side, it scrolls very nicely in Firefox, Opera, and IE7. It's a bit jumpy in IE6. On the Mac side, it also scrolls nicely in Safari and does no harm in iCab (doesn't work, doesn't interfere).

IE5 Mac is a special case. It works poorly in the first table (looks ugly scrolling down, clones many slightly offset copies of itself scrolling up), and does no harm in subsequent tables. However, as even Microsoft has said not to use IE5 Mac, and the first table is readable as long as you are scrolling down from the top, it is not worth trying to do anything about (other than perhaps blocking it from running in IE5 Mac).

I was experimenting with writing something like this myself. I had come to the same conclusion that a separate layer using a cloned header row was needed, but would not have thought to use the event listeners. That gives me an area of JavaScript to study up on.

The changes I would probably make now that I see it in operation and have looked at the code would be:

1) At the top, I'd suggest showing the new layer the moment the scroll goes below the top pixel of the table, so it does not appear to pop on.

2) At the bottom, I'd suggest that the new layer stay on until the bottom pixel of the cloned header aligns with the bottom pixel of the table, then smoothly scroll off the screen with the table itself (perhaps that is too much to ask).

3) I'd suggest that this service automatically apply to all tables having a <thead> or a <th> row, rather than having to list individual tables. This would activate this feature for tables created in a WYSIWYG editor without having to involve the Webmaster. The WYSIWYG editor I am thinking of doesn't create tables with <thead>.The only issue that I can think of there is that it is possible to have a <th> in the first column of every row of a table.

However, before going to all that trouble, I'd like to test it with screen reader software to make sure that the pop-on layer doesn't interfere with the screen reader software reading out the screen. It is a requirement that the page be accessible to people using screen readers. I'm going to test that, and I'll report my results back here.

By the way, an interesting thing I noticed is that if I view the page at 200% font size (something a low-vision site visitor might use), the right-hand nav overlays the left-hand content, but doesn't overlay the scrolling table header. I don't consider that a problem, as I use tables for page layout, which wouldn't have that problem, but you might consider it one. That may be a limitation of this technique.

[MikeFoster]

Hi Charles, Thanks for the ideas and test reports.

1 & 2) Good ideas - I've implemented it.

3) I'll have to think about that.

By the way, an interesting thing I noticed is that if I view the page at 200% font size (something a low-vision site visitor might use), the right-hand nav overlays the left-hand content, but doesn't overlay the scrolling table header.

That has more to do with my demo-page template than the object. But issues like that will come up - modifications to the object will probably be needed depending on the application's html structure and use of positioned containers.

[Charles Belov]

Originally Posted by MikeFoster

3) I'll have to think about that.
That has more to do with my demo-page template than the object. But issues like that will come up - modifications to the object will probably be needed depending on the application's html structure and use of positioned containers.

Wow! That was fast.

Actually, I'm thinking that selecting the affected scope of code doesn't belong in your logic, but in the requesting logic. That is, I would call your logic with the table object I wanted to be scrollable. It would be up to me whether that was tables with specific IDs, all tables in the bodytext, or whatever. That way, you don't have to read the Webmaster's mind.

Anyway, so you don't have to read my mind, I went ahead and made the changes I wanted for non-IE6minus, which was for the heading to scroll off at the bottom of the table. You can see my version of the code. Of course, my changes are contributed back under the GNU LGPL as required. Personally, I am pleased, because this is the first time I have ever been in a position to do so. Hope you like it.

(BTW, you might want to add the copyright and license notice to x_core.js)

Here are my test results:

Windows XP:

Firefox, Mozilla, Opera, IE7: Works great.
IE6: Jerky when scrolling using the scroll bar or mouse wheel.

Mac OS X:

IE5: Excluded (I had to change the detection logic; it appears IE5 Mac doesn't recognize JScript)
iCab: No effect (such is life; doesn't hurt anything)
Safari: Works great.
Firefox: Works reasonably well. Sometimes the layer visibility and contents don't get updated until the site visitor releases the mouse button (livable issue)
Opera: Work reasonably well. Slow response, but not continuously jerky the way IE6 Win is (livable issue)

You'll notice in my code that I reassert the position of the layer continuously during scrolling. This is because of a problem with Firefox Win in which--without the reassertion--if I scrolled up from below the table, and my cursor happened to be off the scroll bar (left or right) at the time the window entered the table, the header row would be partially off the top of the window.


I'm playing around with ideas as to what to do about the IE6minus jerkiness, as it could make some site visitors queasy. I'm thinking on only updating the header location for IE6minus once the movement stops. Of course, there are multiple ways to scroll a page:

- drag the scroll bar (source of the jerkiness problem)
- turn the scroll wheel (also has a jerkiness problem)
- press up/down cursor
- click in the scroll bar area
- press the space bar
- press page up/down
- press ctrl-home/end
- press tab/shift-tab (jumps to next/previous link)

Only the first two methods produce a jerkiness problem. Any ideas?

[MikeFoster]

Hi Charles, I'm glad to see you are having fun with it and making it your own. You're doing great with it

As one example, on my toys page there are several "floater" demos which use "sliding" to smooth out that jerkiness.

Btw... search x_core for "xLibrary"

Sorry I don't have time for much of a reply tonight. Catchya tomorrow.

[Kravvitz]

Originally Posted by Charles Belov

Mac OS X:

IE5: Excluded (I had to change the detection logic; it appears IE5 Mac doesn't recognize JScript)
iCab: No effect (such is life; doesn't hurt anything)

IE5/Mac does recognize JScript. The conditional compilation didn't seem to be working for you?

Which version of iCab did you test in? 3.0.3?

[MikeFoster]

Are my conditional compilation statements incorrect? I'm surprised that it doesn't detect Mac/IE5

    /*@cc_on
    @if (@_mac && @_jscript_version < 5.6) // Mac IE5
      return null;
    @end @*/

[MikeFoster]

Oh I see. Charles, instead of using the sniff (in the init function) try the conditional compile statements I have in mine:

  function init(tId)
  {
    /*@cc_on
    @if (@_mac && @_jscript_version < 5.6) // Mac IE5
      return null;
    @end @*/
    var tbl = xGetElementById(tId);
    var h = xFirstChild(tbl, 'thead');
    var t = document.createElement('table');
    t.appendChild(h.cloneNode(true));
    var d = document.createElement('div');
    d.id = tId + 'thead';
    d.style.position = 'absolute';
    d.style.visibility = 'hidden';
    d.appendChild(t);
    document.body.appendChild(d);
    //xParent(tbl).appendChild(d);
    xMoveTo(d, 0, -100); // this fixed (hides) a rendering problem in IE6
  }

[MikeFoster]

Oops. I don't have my cc statements in the right place. I'm making some changes now.

[Charles Belov]

Thanks for the pointers to the slide function. I'll play around with it when I get the chance (not today).

Yes, I was in fact saying IE5 Mac did not get detected with your code on your page or mine. That's why I switched to the sniffer, which does work, on my page. Since I have zero knowledge about JScript, I think I'll stick with the sniffer. As you can see, I've kept your JScript code for the IE6 Win alteration.

Again, thanks for all your help.

[MikeFoster]

I made a few more changes. Check it out.

1. You can pass it a list of table IDs and/or table Elements. If you pass no arguments it applies the behavior to all tables in the document.

2. It should now do nothing in IE5/Mac.

3. It ignores any tables without a THEAD.

4. The object now has an unload method.

5. The demo properly registers its load/unload listeners.

[Charles Belov]

And I've installed the xSlideTo for IE6 at my test page

It's probably close enough to use, although my next step would be to merge in your changes.

I've got another test page where I tried to have the sliding table header slide back to lie over the original header before hiding, but it doesn't work. The slide ends before it reaches the origin, it doesn't hide, and it's final position seems to vary depending on how fast I scroll (probably depending on the number of scroll events I trigger).

Fascinating.

[MikeFoster]

Great work!

[Charles Belov]

Thanks!

Something's odd here. The moment I use your revised code, and replace

xMoveTo(fh, tx, st);

with

xScrollTo(fh, tx, st, 700);

the scrolling stops scrolling in IE6 Win. (And, yes, I am linking in the xScrollTo script. I think.)

I don't have this problem with your previous code.

If I replace your off-at-table-bottom code with mine Mozilla's scrolling off the header at the bottom becomes jerky compared to my current version. I don't know whether it's your identify-all-tables logic or your revised watcher logic.

Any ideas what might be causing these glitches?

[MikeFoster]

But, why call xScrollTo, I thought you were using xSlideTo? Calling xScrollTo on "fh" (the 'floating header') will attempt to scroll "the contents of" fh.

[Charles Belov]

Because I goofed Thanks for catching that.

I've posted an updated version which has the bottom scroll-off of the header for both IE6 and non-IE6.

Test results:

Windows:

Mozilla - Delay in show and hide at beginning and end of tables. End-of-table scroll-off is jerky.

IE6 - Works well.

IE7 - Slight delay in show and hide at beginning and end of tables.

Opera - Works well.

Macintosh:

IE5 - Only leaves visible copies of the heading behind when I let up on the mouse button. JScript code does not prevent IE5 Mac from running the script; I will need to use my sniffer code.

iCab 3.03 - Doesn't work, does no harm.

Safari - Works smoothly, but doesn't update until I release the mouse button (livable bug). If I scroll all the way up to the top of the page after scrolling down, when I release the mouse button the script leaves behind the right and bottom edges of the scrolled heading.

Firefox - Delay at the beginning of tables. Jerkiness and delay at end of tables. The scrolling of the table itself is slightly jerky.

Opera - Delay at the beginning of tables. Jerkiness and delay at end of tables.

Any idea why the jerkiness/delay at the beginning and end of each table? It's bothersome enough to me--I don't like things popping on or off my screen--to make me stick with my modifications of your original code instead of my modifications of your new code.

[MikeFoster]

I'm experimenting with a different technique for IE6 which was called the Catfish in a SitePoint article. In IE6 it behaves just like it has 'position:fixed', but it doesn't . It doesn't work in IE 4 and 5 but I haven't looked any further into it.

[MikeFoster]

The catfish technique seems to be working very well in IE6

I've also made a correction for when the table does not contain a caption.

As for what happens at the end of the table, I'm content to simply let the header disappear when the last row is reached.

You have to grab the scrollbar and scroll very slowly to see the extra effect you are implementing. I don't think it is worth the effort because it is not likely that anyone will actually see it.

[Charles Belov]

To each their own. Actually, it wasn't the scrolling off I was concerned with as not having it pop off.

Thank you very much for your help.

[Charles Belov]

Ouch! I realized the next step would be to deal with variable-width columns in which the content in some of the columns is wider than the content in the thead portion.

So I started working with my version of your code and came up with my test code and a test implementation. Note that the 5 alerts correspond to the widths of the 5 columns in the table.

The problem is, there is a poor width correspondence between the headers in the new thead div and the original table. Worse, there is no correspondence between one browser and another. Just try Moz/FF vs IE6 or 7 on Windows to see what I mean. Pixel widths are off between the reported alert width and the actual rendered width. Often this is accounted for by the cell borders, but sometimes it is off by 10 to as much as 40 pixels.

This is not going to be easy. I'm thinking of a kludge, such as inserting single-pixel gifs in the header cells of both the original and the div tables.

[Pepejeria]

Its a pity that the following only works in Mozilla, since the issue would be solved with CSS only

<style type="text/css">
table
{
    border:1px solid red;
}

tbody
{
    overflow:scroll;
    height:3.5em;
    overflow-x:hidden;
}
</style>



<table cellspacing="0">
<thead>
<tr>
	<th>header</th>
</tr>
<thead>
<tbody>
<tr>
	<td>scrollable content</td>
</tr>
<tr>
	<td>scrollable content</td>
</tr>
<tr>
	<td>scrollable content</td>
</tr>
<tr>
	<td>scrollable content</td>
</tr>
<tr>
	<td>scrollable content</td>
</tr>
</tbody>
</table>

[MikeFoster]

Charles - I don't get it. The demo resizes the header to fit - even if you resize the window. I don't see why you need to resize each TD. The script keeps the header container the same width as the table, then you just need to use CSS to make the 'fixed table' the same as the original table. The fixed table needs the same CSS applied as the original table - that's what keeps the TDs aligned.

Pepejeria - yes you are right. I tried that before I started on this little project

[PainBehindMyEye]

Very interesting thread to follow. My only issue here is that in FF 2.0, I only see regular tables, nothing scrolls.

Did I miss something here?