I’ve posted this question to several forums and newsgroups… but I haven’t gotten any helpful responses yet. If anyone here has a clue, please feel free to beat me with your cluestick.
My problem in a nutshell:
Even though all of the cells in every column of the two tables on the following test page (http://www.shekinahstudios.com/test/dyntab.html) are set to the same width as all other cells in that column and the tables are set to the same width, in Internet Explorer 6.0, the columns don’t line up. This can almost be fixed if I change the <th> tags to <td>'s, however as soon as I change the text formatting in one of the tables, the problem reappears (and is further compounded when I put things like form elements in the cells). Mozilla 1.4 displays it almost perfectly, except that the columns at index 20 (the 21st columns) end up being off by one despite setting them to the same size. Does anyone know why either of these problems (particularly the first with regard to IE) might be occurring? Because of the intended use of this code, I need to allow the user to put any valid HTML constructs into the table and have it deal with them accordingly.
Further Information: http://www.shekinahstudios.com/test/dyntab.html represents what I consider to be a minimal test case of the problem. I am working on creating library routines that will end up outputting data to multiple HTML tables which must have their columns aligned. They must be in separate tables because of other JavaScript behavior, which I have left out of this test case for clarity. In the interest of not having to require the user to pay attention to pixel level design details, I attempt to calculate the correct column sizes at render-time via JavaScript.
The method is this. The window.onLoad event fires of a function that first sets the width of all of the table cells in each column to the width of the widest cell. It then sets the widths of the table to that of the wider one (I did this to attempt to fix the alignment problem that appears in IE). It then goes about checking to see that the width of each pair of columns is the same (the 21st column fails this test in Mozilla for some reason). It then ensures that all of the properties of the two tables are the same, alerting the user of any differing properties. Though virtually all of the properties are the same, things still don’t line up properly in IE, any ideas? Also, as an aside, the functions for getting and setting the width of the objects were adapted from the xbStyle API. As far as I can tell, they are correct, and the success of checkColumnWidths() appears to indicate as much.
The tough thing is that they’re all going to have tabular data in them… It’d be nice if the corresponding columns lined up… Perhaps there is a better way to skin this cat.
Thanks for the tip adios. That gets all the columns to line up perfectly :)… but it has the unfortunate side effect of clipping any content in any of the cells below the first cell in each column that is wider than the content of the first cell in that column.
I was hoping to expand each column to the size to fit the widest content in that column… the end result being no clipping. That way the user of the library functions that will end up generating this code could just put stuff in cells and have everything line up the way it would if it were all in one table. I suppose it might not be too much to ask of the user to specify a width for each column, however I’m worried about requiring this from the standpoint of separating content from display. It would suck for them to have to recompile the app every time they want to change the font size in the stylesheet… and then there’s the dark world of user supplied stylesheets (i.e. for users with poor eyesight, etc.) those could be trouble.
A curious aside… while not visible in this test case, I have tried test cases that set the height of all of the corresponding rows in two side by side tables to the height of the largest one… and it works flawlessly, it’s just the column widths that are proving to be the fly in the ointment.
Sorry, Matt, I misread your description. Now that I’ve carefully read it - I’m even more confused. Why two tables (header/body)? ‘other JavaScript behavior’ is pretty mysterious. THEADs & TBODIES are designed to synchronize; going it separately requires, as you’ve discovered, almost writing your own miniature layout manager. You’ll never better the browser’s megabyte or twenty in that area. You could DOM-script this, but the question remains: why?
Impressive! I must tip my hat to you adios. It renders perfectly in IE (though I must confess that I don’t completely understand why). It even works if I change the font sizes between th’s and td’s. Really jacks things up in Mozilla, but that’s ok, I could make those rules conditionally included for IE only.
Please allow me to clarify the ‘other JavaScript behavior’ statement. In a nutshell, I’m developing a library that will allow Yardi’s (my employer) programmers to treat HTML tables as an abstraction that behaves like a 2D array for simplicity’s sake. They stuff the “cells” full of HTML content, call the Render() function at the right time, and bingo an HTML table. The need for this simplification is that part of the necessary functionality of this library (really the whole reason I’m making it in the first place) is that they missed spreadsheets’ ability to have frozen cells along the left and top borders while the rest of the cells can be scrolled in any direction. The cells on the left and top borders follow the scrolling in the vertical and horizontal directions respectively. Thus, we need 4 different tables because the cells in each are going to behave to scrolling differently.
It would be nice to allow the programmers to take that table abstraction, specify the upper left of the unfrozen portion, and render() a table with frozen cells. Another intern and myself successfully got a prototype working, but the table required lots of fine tuning in order to render correctly. This sort of fine tuning was unacceptable for use in production, so I was sent to work on streamlining the whole process. In order to free the programmers from having to worry about the extremely finicky dimensions of these tables (and to keep them from breaking when a formatting change is made, like changing the font size across the entire program… or the user’s system not having the indicated font) it seemed that the best way to scratch the itch was to do all of the sizing in the browser by asking it how big things should be.
I hope that makes the rationale and purpose of this rather odd undertaking a bit clearer… and thanks so very much for your help,
Matt
For anyone who’s interested… on a whim, further reinforced by the suggestion of a coworker, I wrapped the content of every <th> and <td> in question in <div> tags and did the resizing on the <divs> instead. The result, PIXEL PERFECT ALIGNMENT IN BOTH IE6 AND MOZILLA… even without the “overflow: visible” attribute, which was a definite improvement… but I was able to break it with further testing. The result is at http://www.shekinahstudios.com/test/dyntab.html.
It renders perfectly in IE (though I must confess that I don’t completely understand why). It even works if I change the font sizes between th’s and td’s. Really jacks things up in Mozilla, but that’s ok, I could make those rules conditionally included for IE only.