Forum Moderators: open
Most are probably familiar with the issue, but if not, the simplest configuration is a table with two columns - the right column occupies most of the page and contains the main page content. The left column is composed of two cells, a skinny one on top, and a larger one below containing site navigation links. The first table row contains the skinny cell in column 1 and the sole cell in column 2. The second table row contains the second cell in the first column.
The problems seem to arise when there is a lot of content on the page, i.e., column 2 gets quite long. When that happens, the "skinny" cell at the top of the first column seems to stretch out, even if a height has been specified in pixels. This is really the crux of the problem - browsers tend to ignore the cell height specification at times even when there is no internal element (text or image) to force it to a larger size.
I've experimented with various solutions, including specifying a large height value for the second cell containing the nav list - this works, but makes the page needlessly long for pages with short content. (Annoying to visitors who scroll down looking for more, or worse, print out the page and get a pile of blanks.)
I know there are other ways to skin this cat, like putting the nav menu on the right, but it seems like something that shouldn't be that difficult to fix. Last time this came up here, it seemed that the discussion trailed off without a definitive solution. Is it indeed unsolvable?
Our previous Table Trick thread [webmasterworld.com].
And about those right hand menus---
Usability.gov [usability.gov] recommends right hand nav, based on usability research.
The "second workaround" is straightforward, but it presumes you can control the table structure on each page. Using page templates or dynamic pages where the text content just gets poured into a cell would make this more complex - short content would stay in one cell, long content would have to be split between the two tables. :( Definitely a good way to go, though, if you have the flexibility to split the content. (Actually, I don't think a new table is even necessary - starting a new row in the same table would work equally well, I think.)
I'm going to play with the other fix possibilities. It's really an aggravating problem, since no fix is needed most of the time. When you get a super-long page, though, suddenly the browser forgets about specified cell heights. Thanks for the suggestions.
Table works fine with IE5, Opera 5, and Omniweb, but Netscape 6 splits the table top and bottom instead of side to side!
The problem is on the site in my profile, on the page community.html in the bottom frame.
Could someone check this out and give me an answer?
Thanks for all the geat ideas and insight you all provide. This forum has been very valuable to me.
foggy
(edited by: tedster at 12:25 am (utc) on Mar. 19, 2002)
On your problem page, you have a div before the table that gets closed two times instead of once. Might be what confuses NN6.
Many thanks for the help. The double div tags wasn't the problem, but i appreciate your input and polite correction of my URL faux pas.
The problem was , believe it or not, no closing TD or TR tags !!!!!
These modern day browsers are more robust than we give them credit for when they can compensate for horrendous coding by culprits such as moi!
That's one of the reasons I use Homesite - I can do continual validation checks all the time I'm working on a page. It helps to catch my flubs early.
No - Sorry, I think not.
My practise is to set up the table using initial blank rows and columns of 1px gif's set at the biggest likely size, and then position the cell content to look good. I find this more reliable than trying to set the cell sizes with attribute statements, and in bigger tables, it saves on code weight. It is easier than trying to exactly fill table cells with content plus gaps to keep the proportions looking even
