Freeze panes at top of table like Excel

I have this php script that displays data retrieved from a mysql table in a html table. http://www.ykfp.org/php/lyletrap/tabletotals.php Now the customer asks if it would be possible, when the user retrieves more than one page of data to "freeze the header row on top of the table like in Excel". Well, it's not possible for me. But for a real web programmer it might be. Is there a way?

This signature line intentionally blank.Edited by MajorGeek on 03/19/08 10:22 AM (server time).

I'll preface my response by saying that I don't remember flat off the top of my head how to do this, but I do know that it's possible. The key is to take advantage of the fact that tables can be divided into sections and that you can use CSS to make each section behave in a particular way. The three sections that you can divide a table into are called thead, tbody, and tfoot.

To get the headers to stick at the top, the first thing you will want to do is to put the grey boxes into a <thead> and put everything else into <tbody>. Then, using CSS, I believe you can use the height property to limit the size of tbody and then use overflow:scroll to add a scroll bar so that your customer can see all of his data.

While you're at it, I would also recommend putting the blue total boxes at the bottom into a <tfoot> because then you can make sure they always show up as well. Your customer, then, would always be able to see the headers, always be able to see the totals, and is free to scroll through the data.

Unfortunately, any more detail than that is more than I can conjure up from the depths of my brain at the moment. Hopefully that at least gives you a starting direction. If you still need more help, feel free to ask and I'll see if I can find any other resources to explain what I'm talking about a bit more.

I read up on thead, tbody, and tfoot, but I can't get them to work in my table. http://www.ykfp.org/php/lyletrap/tabletotalsthead.php I must be missing the style setting that makes the header stay at the top of the page. I couldn't find anything on that.

I got a frames version to work. I wanted to avoid frames, and it's tricky to get the header columns to line up with the body columns: http://www.ykfp.org/php/lyletrap/tabletotalsframes.htm

This signature line intentionally blank.

Try this awesome version out.

-- si-blog --

In reply to:

---

Try this awesome version out.

---

That, actually, is *very nice*!

--rlparker

Aha! That's exactly the page I was thinking of when I was describing the trick in my post above. Or, well, it would have been, if I'd remembered it at the time. It is where I learned that trick from

Wow, that is so cool. I had no idea you could do so much with styles.

I guess what I need to do is grab from the view source window of my browser everything after /*end basic styling, stick it in my page source between style tags, then edit my thead and tbody blocks to use the appropriate class.

Hey, when you get to this many lines when writing a reply in this forum you suddenly get a scroll bar on the right of the field. Is this the same kind of css trick except it somehow counts lines?

One and only one online html reference said that you had to use thead, tfoot, and tbody and they had to be in this order, but that doesn't seem to be the case. This one: http://www.w3schools.com/tags/tag_thead.asp

This signature line intentionally blank.Edited by MajorGeek on 03/19/08 05:03 PM (server time).

In reply to:

---

when you get to this many lines when writing a reply in this forum you suddenly get a scroll bar on the right of the field. Is this the same kind of css trick except it somehow counts lines?

---

Nope ... that's just the normal behavior of a text area field in a form that has attributes set to a given number of lines ... when that number is exceeded, the form field does not grow but shows a scroll bar instead.

--rlparker

In reply to:

---

One and only one online html reference said that you had to use thead, tfoot, and tbody and they had to be in this order, but that doesn't seem to be the case. This one: http://www.w3schools.com/tags/tag_thead.asp

---

While it's true that browsers are unlikely to enforce this restriction, the order of thead, tfoot, and tbody is a mandatory part of the HTML standard and your pages will not validate unless the correct ordering is observed. Of course, this is true of a lot of things in web development, where a web browser is a lot more permissive of mistakes than the standard dictates. The reason is that, at the end of the day, standards exist to say what is correct and browsers exist to display any webpage they see in a way that makes sense to the user, and since even today a lot of pages are not written correctly according to the standard, browsers need to allow some flexibility.

I would, however, encourage you to write your table in the way that the standard dictates: thead, tfoot, tbody. It may not seem like it matters much now, but I can say from personal experience that not paying attention to the little things can make a real mess further down the line.

Well, I often do that. You will need to use Javascript and CSS.

How it works is that we will put tables to different layers and use javascript to control which layer to display. Let me try to explain. I hope I won't confuse you.

For example: There are 3 tabs in your top freeze head. "Tab 1", "Tab 2", "Tab 3".

If you click on "Tab 1", you will see "Table 1" and vice versa.

So what you will need to do:

1. for the tab. Usually I put tabs in a table so that I can use onMouseOver, onMouseOut behaviors.

<td id="menuTab1" onClick="openTab(1)">Tab 1</td>

2. put the tables into different layers

<div id="menuContent1">
Table 1
</div>

3. complete javascript functions.

function openTab(args){
for(i=1; i<=3; i++){
if (i==args) document.getElementByID("menuContent"+i).style.display = "block";
else document.getElementByID("menuContent"+i).style.display = "none";
}

Now, if you click on Tab 1, you will display Table 1. If you click on Tab 2, you will display Table 2.

These are not complete codes but to give you a guide line. You can view source and copy complete codes from
https://www.godaddy.com/gdshop/hosting/shared.asp?ci=9009

That looks cool in Firefox... but am I the only one that sees it like this in IE7?

I only ever use Firefox, but wanted to see if that was something that IE would wreck.

Yeah that's what I see on IE7 too.

In reply to:

---

That looks cool in Firefox... but am I the only one that sees it like this in IE7?

I only ever use Firefox, but wanted to see if that was something that IE would wreck.

---

No you are not the only one ... ya gotta "love" good ole IE (not!)

--rlparker

Well, two more reports proves it's not just me.

Unfortunately, when something breaks that badly, it either doesn't make sense to use it... or you need to add some browser sniffing that triggers a Plan B.

That type of breakage makes it look like you installed a site template and forgot to add your content. It needs to at least "break" into a normal table, without the pane freezing effect, but still retaining the content.

If that can't be straightened out, then it would probably make more sense to use a floating DIV that returns to the top when the page is scrolled (like some sites do with their menus.

Those can probably break as well, but I think it would do so more gracefully, if no backup plan is in place.

I think if you're not going to thoroughly test it and work out the bugs, it's probably just best to just repeat the header every so many rows.

That can easily be done with a loop, if generating the table dynamically, where you just count the rows as you write them.

How about this java demo: http://java.sun.com/docs/books/tutorial/uiswing/components/table.html

Great, more scripting languages to learn! In the last couple of years I've been confusing myself by trying to learn VB, Perl, PHP, and Python simultaneously. Now I have to take on CSS, Java and Javascript. Meanwhile, my expertise in Primos and Henco Info becomes less and less marketable.

This signature line intentionally blank.

I've prepared a Gecko-friendly proof of concept that is simple to follow, but it won't work on IE without a festival of hackery.

-- si-blog --

At least that "breaks" in IE7 as a normal table, rather than losing all the data like the other one.

I guess if generating it dynamically, you could always check for IE7 and repeat the header every 10 rows, or something similar.

Edit: The other downside of breaking is that when it breaks in IE, it breaks for most people.

What's weird is that it doesn't break in earlier versions of IE. Explorer 6 renders the reference version just fine. In that sense, the new version is actually a step backward since IE6 doesn't handle it properly.

Unfortunately, I don't have a copy of IE7 readily available, but I managed to find this, which works in both Firefox and IE6. Maybe we can get lucky and have it work in 7 as well?

Nope - that breaks worse than all of the others in IE7.

Even if you luck out and find one that covers the bases, or can be modded to work... it's just a temporary fix until they make sure IE8 breaks stuff for no reason.

Oh wow. I think I might have figured out how "the reference version" makes this work. Turns out the secret is that it doesn't make the table scroll, but rather leaves the scrolling to a wrapper and some other hackery to simulate a scrolling table. The trouble is, that reference code hasn't been updated since before IE7 and the new browser broke some of the CSS filters the author used to make the hack work in IE6.

Since I'm feeling sort of bored tonight, I'm updating the code to make it a bit more futureproof and to pick up IE7 support. I'll be putting the result on my blog later and I'll be sure to link you guys to it when I finish.

As promised, here's my blog post describing what's going on with scrolling tables in IE7. For those who don't want to read through it all, here's a direct link to the implementation.

In addition to making it work in IE7 I've tried to clean the original source up a little bit, so hopefully it'll be easier to understand if anyone, thread starter included, ever needs to take a peek at how it works

That works in IE7 but has a horizontal scroll bar.

The header columns break into two rows in Firefox and there's also something screwy with the height, as the table border goes all the way down the page, as if the full table was shown.

I see the last column as being bigger in both browsers, but didn't know if that's how it was supposed to be.

... haha. I actually knew about those bugs and fixed them locally, but forgot to upload the file! Thanks for pointing it out. It should be fixed now.

And yeah, the last column is supposed to be bigger. The second column is actually slightly larger than the first as well, but the difference isn't as pronounced.

That fixed the header columns, but in Firefox v2.0.0.12, the border is still all the way down the page, basically the same size as the table would be without the scrolling.

If it was the last thing on a page, then it would look right without a border, but in the middle of a page it would push everything below it to the bottom.

I also still see the horizontal scroll bar in IE7. Is that gone in your browser? My version is 7.0.5730.11, if that makes a difference.

Ok, I fixed the Firefox thing, so that should be taken care of.

I think I've fixed the IE7 issue as well, but about that, are you using the "classic" or "XP" Windows theme?

From the looks of things, when Microsoft added the new XP theme, they increased the width of the scroll bar by a pixel. This code relies on subtracting out the width of the scroll bar from the width of the table. Those grey scrollers, it seems, are a uniform 16px in width, which is a fact that the original author relied on in performing the calculation and which I carried over to the revision. Unfortunately, the XP theme has scrollbars 17px wide, which is why you were seeing a 1 pixel side-scroller. I, on the other hand, was writing this on a computer running the Classic theme, with 16px scrollbars, causing there to be no side-scroller. The "fix" I've applied is to simply force the side-scroll to disappear, and it is gone now in IE7 no matter which theme I use.

That said, if anyone has IE6 running in Windows XP using the XP theme, I would be very interested in knowing if you see a side-scroller. I do all my IE6 testing in Linux, so I don't have a particularly good way to check this on my own.

I have the XP theme - and it seems to be fixed now in both browsers. I would guess that pretty much makes it safe for use... at least until MS breaks it again.

I've tried your styles on my table through a few different iterations, but I still have some things I can't fix. What am I missing? http://ykfp.org/php/lyletrap/tabletotalscss5.php

When I included your h styles, my header columns no longer align with the body columns. Without your h styles the scroll bar disappeared.

I tried to increase the height: in both places. I get more lines displayed on the screen, but my table outline still goes off the page.

When I look at this on Windows XP with IE 7.0.5730, it blows up. I get very tall lines, no scroll bar. My current Windows theme is a modified XP.



This signature line intentionally blank.

I finally got this table to look like I want without frames: http://ykfp.org/php/lyletrap/tabletotalscss7.php. I finally caught that for the last 6 iterations of this table, I missed putting a <div id="tableContainer" class="tableContainer"> tag around my table after defining it. Now it's working like I had hoped, in both Thunderbird and IE 7. Well, I learned something. Thanks for your help.

This signature line intentionally blank.Edited by MajorGeek on 04/01/08 01:27 PM (server time).

Fixed link (there was a period on the end).

Not really a big deal, but I'm not sure if you noticed that in IE7, there's a 1 or 2 pixel gap above the header cells. If you scroll up and down while looking at it, you can see it moving past. I don't see it in Firefox though - looks good!

The one annoying thing about the frozen pane effect is that depending on how people browse, or use a scroll wheel, you have to horizontal scroll to get the table's scrollbar... at least that table size with my settings.

I've noticed that 1 or 2 pixel gap in IE as well. Is that something I did? Is there a fix?

Here's a mystery. Some people using IE7 have reported that the header bar is placed a couple rows down in the table. They even sent a screen shot: http://ykfp.org/images/shot.jpg Another guy told me he saw that effect once but then the problem "fixed itself". http://corky.net/scripts/brazil.html

Why can't MS follow standards? Can I get the EU to sue them for another billion over this?

Now there's a new problem. The "customer" now asks if I can make the table smaller, like 680px, so it will fit within his frames. I tried some simple things, but the header columns got out of line with the body columns. Then I changed some other things, and the table's gone real wacky in both browsers. http://ykfp.org/php/lyletrap/tabletotalscss8.php Maybe I'll go back a step and try again.

This signature line intentionally blank.Edited by MajorGeek on 04/02/08 11:37 AM (server time).

Well, let's see here...

In reply to:

---

The "customer" now asks if I can make the table smaller, like 680px, so it will fit within his frames. I tried some simple things, but the header columns got out of line with the body columns.

---

The reason that things are getting out of line is because the text you have in these boxes is too wide. The way browsers implement tables is that they'll generally obey your width settings as much as possible, but they're more interested in getting the table displayed correctly than they are in strictly following your width settings. If text forces the browser to make some columns wider (and later columns narrower) than you've specified, then that's what the browser is going to do.

In your case, all of your text is crammed in there pretty hard. Your date column, in particular, is throwing off everything in the table body. The text in your table header doesn't leave a whole lot of flex room. Something definitely needs to give, which means either you need to reduce the font size until things fit, reduce the number of columns somehow, or you tell your customer that 680px isn't possible.

In reply to:

---

They even sent a screen shot: http://ykfp.org/images/shot.jpg

---

I have no idea what to make of this screenshot. Or, I should say, I have seen IE6 and IE7 do stuff like that before, and fixing it tends to be a very detail oriented compete and total pain. It's entirely possible that getting the width issues fixed will (either directly or incidentally) fix this problem, too.

Since this is a topic of discussion, could you folks check out this sample that I did a long time ago and let me know if any given browser has issues?

removethismungepleaseNebula-RnD.com/freeware/ScrollingTable.htm

The "generate new report" link isn't intended to work. This was intended to be a simple POC for people in my business community asking how to do the scrolling table thing.

Email to j2fp7im02 - at - sneakemail.com, or comment here.

I really hate spam, sorry for the munges.
Thanks!

In reply to:

---

I've noticed that 1 or 2 pixel gap in IE as well. Is that something I did? Is there a fix?

---

I haven't even gotten around to looking at the code yet, but I'd guess you might need some conditional comments for IE.

Personally, I tend to stick with things that don't require too much compatibility-hacking, since it always gives me the bad feeling that a future version of one of the browsers will break it again.

If nothing else works out, and you absolutely have to use that, one solution would be to design it once for each browser so it's flawless... then just include the right one based on the user agent. If I did that, I'd just pick the top 2 or 3 browsers, then choose one as a default for the other oddballs, or just default to a regular table with repeating headers ever 10 lines or so.

Disadvantage: More work.
Advantage: When a browser breaks it, you only have to deal with that browser and not worry about whether or not your "fix" will break it in another browser.

I don't necessarily mean repeat the whole table with data each time, but just multiple formats. It could just be one function that draws up the the correct table for that browser & populates it with the same data either way.

Other than that...

Have you tried column widths in both fixed pixel widths and percentages? I'd guess percentages would break easier between the header & table columns not lining up because of the amount of text in a cell.

Another guess would be that images might force things into place. Maybe if the header cells were images, so the amount of text (or its size) couldn't break the row... then maybe a bottom row in the table with invisible 1px gifs set to the same width as each column?

I'm not sure if it would work or not, and it's something I wouldn't even bother doing since it would remind me too much of dealing with the older versions of Netscape.

I'd probably say this: If it's just for one client, do whatever makes it work and has the least chance of breaking. If it's something you want to start using for others and implement it in different types of sites, I'd probably put the work into making sure it works perfect in each of the main browsers, even if it's a LOT of extra work.

Kinda like how some people write nice scripts the degrade beautifully over a bunch of different technologies, rather than breaking over a single problem like cookies, Javascript, Ajax, etc...

In reply to:

---

Why can't MS follow standards?

---

Because then they wouldn't be MS.

It looks fine on FireFox 2.0.0.13 on Linux, that Vista thing, and on Windoze 98SE.

Also looks fine on epiphany 2.20.1 on linux

Internet Exploder 6.0.2800.110615 displays it "ok" on Win98SE, but adds spacing between the cells - not objectionable but different than the others.

Same as above re cell spacing issue on IE 7.0.6.6000.16609 with that vista thing (no SP1 installed yet - I afraid )

--rlparker

In reply to:

---

Win98SE

---

Srsly?




-- si-blog --

In reply to:

---

Win98SE .... Srsly?

---

Hey! He asked, so I tested with everything I had laying conveniently around ...

... and I find *that* preferable to that vista thing in a lot of ways and for several reasons! Srsly!

--rlparker

Is the stuff in white supposed to move? If not, then there's a problem on Firefox 3.0b4 on Linux, because it scrolls right along with everything else. Beyond that, it looks ok.

Thanks to those who tested it - I really appreciate it.
The first column in white is only supposed to scroll vertically, but always remain visible even when horizontally scrolling.
The top row in white is only supposed to scroll horizontally, but always remain visible even when vertically scrolling.
I'd be very surprised if the top row or side column scroll but will take a look if they do. Then again, hey, it's only a demo.

RL - I believe the huge cell size was intentional just to give the table some width to demonstrate the scroll. If you do not see that then your browsers are doing you a "favor" and resizing cells despite the explicit code setting.

Regards to all.

In reply to:

---

The first column in white is only supposed to scroll vertically, but always remain visible even when horizontally scrolling.
The top row in white is only supposed to scroll horizontally, but always remain visible even when vertically scrolling.
I'd be very surprised if the top row or side column scroll but will take a look if they do. Then again, hey, it's only a demo.

---

I would definitely take a look at the Firefox beta, in that case, because those white boxes are not doing what you just described (at least for me).

If a new Firefox beta is available which does not behave like prior releases and which is not compliant with other browsers (even IE works for this one) then I think someone is FLOSSLand has screwed up. I'll make some inquiries. Thanks.

Just confirmed the same behavior in Firefox 3b5. If it helps, Firebug reports this error when I load your page:

topRow.firstChild.style is undefined
http://-obfuscationgoeshere-nebula-rnd.com/freeware/ScrollingTable.htm
Line 51

If you do find anything out, I'd be quite interested in hearing what's gone on to make your table code suddenly stop working.

In reply to:

---

Win98SE .... Srsly?

... and I find *that* preferable to that vista thing in a lot of ways and for several reasons! Srsly!

---

I'll take Win98SE over Vista anyday.

It absolutely flies on these new fang-dangled PC's

By reducing the text size, changing the date format, and fiddling with the column widths and container widths, I have a version that just about works acceptably in Firefox and IE7. However, I can't figure out why IE 7 wants to wrap the date into three lines. http://ykfp.org/php/lyletrap/tabletotalscss10.php

Header and table columns don't line up in Firefox on Linux, but my customers are not going to be using Linux.

This signature line intentionally blank.Edited by MajorGeek on 04/09/08 04:10 PM (server time).

In reply to:

---

By reducing the text size

---

One problem with that will be user preferences, enlarging the font. No idea of what percentage that would affect, though.

I guess one way to avoid that to an extent (maybe?) would be if there's room to go with fixed widths and make each column wide enough to handle a jump or two in font size on the largest entry you'd expect.

Like I said, I tried reducing the text size down to what I thought was ridiculously small, and IE7 still wrapped the text. What I found was I had mistakenly left a 21px width in that first column in the tbody, which was too narrow for any legible font size.

Still, some IE7 users report that the heading is first seen about three rows down into the table until they refresh.

This signature line intentionally blank.

I haven't gotten the header to float down that far with any of the links posted so far, but I did just notice that in IE7, I still see the 1px gap at the top... which isn't really noticeable until you scroll and see the text move by. That's not really a big deal, though.

It's happened. Just as seiler predicted back on 4/2/2008, IE8 is in wide use now and this script (http://www.ykfp.org/php/lyletrap/tabletotalscss09.php ) doesn't work correctly in IE8.

IE8 also breaks scjessey's Pure CSS Scrollable Table with Fixed Header (http://www.imaputz.com/cssStuff/bigFourVersion.html)

Do I need to change the if that detects IE so it also detects IE8, of is it more involved than that?

Found this example that works in IE8 using a simple <div> http:// http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=357

This signature line intentionally blank.Edited by MajorGeek on 07/28/09 04:14 PM (server time).

In reply to:

---

It's happened. Just as seiler predicted back on 4/2/2008, IE8 is in wide use now and this script (http://www.ykfp.org/php/lyletrap/tabletotalscss09.php ) doesn't work correctly in IE8.

---

If something works, Microsoft will find a way to break it.

I haven't even installed IE8 yet, so I've yet to have the pleasure of seeing everything that's broken.

In reply to:

---

Do I need to change the if that detects IE so it also detects IE8, of is it more involved than that?

---

I'd guess it's just doing a matter of whatever it takes to get it going again... until the next time it breaks.

This is the type of thing where I'd probably only serve it to browsers that you know it will work with, then have it load something more generic that will pretty much always work for everyone else.

That way, you don't have to rush to fix anything when MS breaks stuff. Instead, you can test it on a new browser at your convenience, then roll it out on the site when it's ready.

In reply to:

---

Found this example that works in IE8 using a simple <div> http:// http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=357

---

The idea is simple enough, but as people are pointing out in the comments, you can break it if you don't control the size of the data.

I haven't messed with it, but if I wanted to try that one, I'd probably see if I could keep it within 1 table instead of two. Maybe put the div & second table in second single-cell row with fixed dimensions. I'm not sure how that would react to different sized entries... but maybe it would help force the whole thing to adjust.

Maybe that wouldn't work, but it was the first thing that came to mind since it relies one two tables lining up with each other.

In reply to:

---

This is the type of thing where I'd probably only serve it to browsers that you know it will work with, then have it load something more generic that will pretty much always work for everyone else.

That way, you don't have to rush to fix anything when MS breaks stuff.

---

I like this approach. If everybody served only the most generic stuff to IE browsers, reserving the "nice" stuff for more capable browsers, there might actually come a point where users would be more prone to use "good" browsers~

--rlparker
--DreamHost Tech Support

We really shouldn't blame poor performance on the motor when we're using bad fuel.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

How To Install PHP.INI / ionCube on DreamHost

Cool to see this thread come back to life. I am surprised that anyone is still using Internet Explorer, though. I've been viewing the Matrix directly for a while now, so I don't need browsers anymore.

-- si-blog --