Table Tricks and Truths

By Peter Cooper

So, you've come to read about tables...

Whether you're a FrontPage user or a professional HTML hack, you've probably used tables at some point. Far more so than frames, they're the tool of choice for developing page layouts by the majority of Web developers.

However, intermediate and advanced developers alike often face problems with tables that they didn't expect. A table may look incorrect in Netscape, things may not be working properly in IE, tables can be so complex that even the professionals forget certain aspects of their use. I shall try to cover some of the issues involved, and some of the Frequently Asked Questions about tables which we receive. So, if you'd like to follow me, let's crack some FAQs one-by-one.

Where Have All the Cells Gone?

Assume the following code is in a page with a plain white background. The code simply dictates that a table should be rendered with a black background throughout. There is a single row, made up of two columns of no defined widths. The first column contains nothing, the second column contains two dummy paragraphs.

<table width=100% bgcolor="#000000">
	<tr>
		<td>
		</td>

		<td>
		test</p>test</p>
		</td>
	</tr>
</table>

However, when we view the code in IE, and then NS, we notice a major difference. In IE, there is a 100% browser wide black bar. We would assume this to be correct since we have two columns taking up 100% of the width, and the background of the entire table should be black. The two dummy paragraphs are providing the height of the table.

When we take this into NS (Netscape), on the other hand, we notice a different result. There is only black on the right hand side of the screen, showing us that the first empty column doesn't have a black background like it should. It's part of the overall table, so why isn't its background black too?

Unfortunately, I can't tell you the reason for this, it's merely how Netscape renders its tables. The solution? Fill all empty cells/columns and rows with something, from a   (a non breakable space), or with a 1-pixel transparent GIF.

Incorrect Widths

Let's take our previous code and adjust it slightly so that the first cell has a background of red, and the second a background of blue, so that we can differentiate between them. Let us also put the same content within each cell, for fairness. Let's also define cell 1 as being 100 pixels wide, and the second cell as * wide, to imply that it should take up the rest of the 100% browser width defined by the main TABLE tag.

<table width=100%>
	<tr>
		<td width="100" bgcolor="#FF0000">
		test</p>test</p>
		</td>

		<td width=* bgcolor="#0000FF">
		test</p>test</p>
		</td>
	</tr>
</table>

Now, when we load this up in IE, things look great. We have a red strip on the left which is 100 pixels wide, and a wide blue bar on the right extending to the far right of our page (taking note of the border).

When we load it up in NS, however, things aren't so wonderful. We discover that the left cell, supposed to be only 100 pixels wide, now takes up around 80% of the width of the page, and the blue area has only a tiny area to the right. What's going wrong this time?

Once again, there is no immediately logical reason for Netscape to act in this way. However, it appears that Netscape doesn't honor the * in the same way that Internet Explorer does, even though this device appears in the official HTML specifications. But, once again, there is a solution to our width problems.

		<td width=* bgcolor="#0000FF">
<p>If we place a long run of text into this cell, like so, 
then Netscape will allow the cell its maximum width which
is 100% of the browser, minus the 100 pixels for the
other cell. So, as you should now discover, the cells
are the correct size in both browsers.</p>
		</td>

With this 'padding' text in the * cell, it will now expand to its maximum permitted length. But how convenient is this? Unfortunately, there are no hard and fast ways to permanently fix this problem, although there are several workarounds. If you make your table a defined width, say 600 pixels, and your cells are both defined pixel widths, then there will be no problem and Netscape will get the widths correct without the padding text. Likewise, if you define all widths in percentages too. It just seems that Netscape doesn't like to mix measurement units within tables, and really isn't too keen on the * operator.

[ Click here to move to the next part of the article ]

This article first appeared in January, 2000.

Refresh Daily
Join Editor-in-Chief David Fiedler The Editor With No Time and find truth, justice, and a clue or two.

[ Site Map ]

ActiveX / VBscript

Animated GIF Archive

Browsers

CGI / Perl

Database Connectivity

Design / Graphics

E-Commerce

HTML-Advanced: DHTML, CSS

HTML / Site Authoring Tools

Intranet/Groupware

Java

JavaScript

Multimedia: Audio / Video / Streaming Technologies

Opinions

Refresh Daily: Editorial Column

Security

Servers & Server Tools

Site Design / Graphics

Site Management / Marketing / Log File Analysis

Tutorials

VRML / 3D

XML