WebDeveloper.com �: Where Web Developers and Designers Learn How to Build Web Sites, Program in Java and JavaScript, and More!   
Web Developer Resource Directory WebDev Jobs
Animated GIFs
CSS
CSS Properties
Database
Design
Flash
HTML
HTML 4.01 Tags
JavaScript
.NET
PHP
Reference
Security
Site Management
Video
XML/RSS
WD Forums
 Client-Side
  Development

    HTML
    XML
    CSS
    Graphics
    JavaScript
    ASP
    Multimedia
    Web Video
    Accessibility
    Dreamweaver
    General
    Accessibility
    Dreamweaver
    Expression Web

    General

 Server-Side
  Development

    PHP
    Perl
    .NET
    Forum, Blog, Wiki & CMS
    SQL
    Java
    Others

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

 Etc.
    The Coffee Lounge
    Computer Issues
    Feedback




Table Tricks and Truths

by Peter Cooper
First published: January, 2000

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 &nbsp; (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.

Gaps and Spaces

Many intermediate and advanced HTML coders will already be aware of cell borders, padding and spacing. However, there are coders who continue to ask questions about these aspects of coding tables, and this is the best place to cover them.

The CELLPADDING, BORDER, and CELLSPACING attributes should all be within the TABLE tag to guarantee compliance between the two main browsers.

The CELLPADDING attribute defines the amount of pixels to pad a cell with. Your cell may be 400 pixels wide, but if the cellpadding is set at 5 pixels, then an internal border of 5 pixels will be present within the table. It's not visible, but it's there so that your content doesn't sit right on the edges of the cell. As such, a 400 pixel wide cell with 5 pixels padding, has an effective usable width of 390 pixels.

The BORDER attribute defines the padding around the entire table. When BORDER is not equal to zero, a visible border will be placed around the outside of the table which is x pixels wide (x being the value, in pixels, assigned to the BORDER attribute). The border gives the entire table a 'raised' feel making it look slightly more 3D. An example is shown below:

This table has a border of 5 pixels.. and this cell has a padding of 10 pixels, as defined by CELLPADDING.

This table has a border of 2 pixels.. and this cell has a padding of 2 pixels, as defined by CELLPADDING.

The CELLSPACING attributes defines the space between all cells. This allows breathing space between the cells, and doesn't squash the content of the cells at all, as with CELLPADDING. Some examples are shown below:

This table has a CELLSPACING of 12 and a CELLPADDING of 0. This table has a CELLSPACING of 12 and a CELLPADDING of 0.

This table has a CELLSPACING of 3 and a CELLPADDING of 0. This table has a CELLSPACING of 3 and a CELLPADDING of 0.

You can use each of these elements individually or all together, but if used they must only be used within the opening of the TABLE tag as so, where x, y, and z are replaced with your own values:

 <table border=x cellpadding=y cellspacing=z> 




HTML5 Development Center


Recent Articles