Table bug

Ah... tables! When they were first introduced every designer in the world (except sceptical geeks and extremely professonal guys) thought that finally they got themselves a precise tool and it wouldbe finally possible to have a by-pixel control over layout.

Hey, some people might say... isn't HTML all about device independence? Shouldn't we all be using only relative values, avoiding using pixel dimensions? Well, it is true, but most web designers would exchange compatibility for greater control. Never mind, this is not a style discussion and not a UNIX vs PC war... though I wish it was, because TABLEs give me a headache. Big one.

Wanna know why? Well, sadly I am unable to test these findings on Microsoft Internet Explorer (let alone other browsers), so the following "bug" is only definitely applicable to Netscape Navigator. Let's create a table that is 250 pixels wide and consists of two cells - one is 100 pixels wide, another is 150 pixels wide.

Well, that is easy, you might say. Just write the following code:

listing 1

So... what's happening with the table? Well, the problem is that because there is nothing inside the table, i.e. nothing between <TD> and </TD> tags, Netscape assumes it is not worth its while to actually produce a table. No problem, let's put something in the first cell.

But what if you do not want to have anything in one of the cells? Well, you have to put at least something in there. A tricks some of us use is simply to put a <BR> tag inside a dummy cell. So let's alter the code a bit:

You might think that empty cells is an artificial example, but designers use empty cells all the time. Let's say you have a background image that vertically divides a page into two parts. A good example is... this page. The "jagged page" effect is created using a background image. To make sure your text stays where you want it to stay (either right part of the background image, e.g. a "Back to" button on this page; or left part of the background image, i.e. the main text of this page) you have to use a table.

Still, you do not see any problems with the table. Now, let's try to fill the right cell with some text:

Let's compare this result (no.4) with the previous result (no.3):

You can see that after simply inserting some text into one of the cells, the cells changed (!) their widths by themselves! If you don't see any difference in size, your browser works just fine. What have you done wrong? Nothing. This is a bug. And it is a very annoying bug. Why? Well, because now it seems that the dimensions of the cells and possibly the width of the whole table can change depending on what you have inside the cells. And how are you supposed to control the text flow so that it does not cross the boundary you do not want it to cross?

Don't get too annoyed, there is a workaround around this problem. But first, let's see what will happen if you add text to the left cell:

And now all three results one after another:

Now, in my browser three tables above are completely (!) different. Depending on how much text you add, the dimensions, explicitly specified magically change themselves.

You cannot simply adjust the dimensions. Say, you make table a bit wider, tamper with cell widths. Because even though you will by the end manage to make the table look exactly as you want in the Netscape, it will look completely different in any other browser that displays tables correctly!

Ok. What's the solution? Netscape recognised the problem and provided a special tag, <SPACER>. What does it do? It reserves an exact (by-pixel) amount of space and is mostly used to create exact-width table cells. How does it work? The following is the description of the SPACER tag, listing all the available attributes.

(a) <SPACER TYPE="horizontal" SIZE="100">
(b) <SPACER TYPE="vertical" SIZE="100">
(c) <SPACER TYPE="block" HEIGHT="10" WIDTH="10" ALIGN="align_type">

(a) and (b) are pretty much the same, they reserve size number of horizontal or vertical pixels.

(c) reserves a block of space and you can think of it as an image. ALIGN is an attribute that takes any values that <IMG ALIGN> does.

Ok. Let's try it in action. In each cell I will reserve a space using SPACER before writing any text. Here is the code:

And here is the result. Some previous results are also displayed for comparison:

Let's test if <SPACER> really solves the problem. Let's delete the text from our cell, leaving only <SPACER> tags and adding <BR> attributes and see if anything changes (I am not listing the code, it should be obvious):

It looks exactly the same. So... the problem solved? Well, the <SPACER> tag obviously works fine, although I found that it sometimes behaves weirdly. But sad news is, it is not a standard HTML tag, it is not supported by HTML or anyone else except Netscape and I believe will be dropped in next reincarnations of Netscape Navigator. So you are better off without the SPACER. What should you do? Well, the trick is to imitate the SPACER tag.

Create a transparent 1x1 pixel gif and use it instead of SPACER. If you do not know how to make a transparent gif or you are too lazy, just save the following link (right-click and "save the link" usually): trans.gif.

Now, this is how you use the image:

And here is the result, compared with the previous result that used SPACER:

And so, you can see that it looks exactly the same. And we come to the conclusion of the lengthy discussion of the Table bug and a workaround. I am not sure whether any other web browsers have this bug, but hey, now that you know the workaround, who cares?

A final addition, a small tip to reward you for lengthy reading. If you have a background similar to the one that you can see on this web page, you might not want a text to enter the "jagged edge" area. So just create three columns, one for left text, one for jagged area, which is empty (but remember, empty means that it has a transparent image, otherwise the dimensions will all mix up) and the last one for right text. Easy, but sometimes people get into all sort of difficulties because of that.