Tables are, in my opinion, the most important HTML element in crafting Web pages. They act as containers for text and images. They organize and separate portions of a page, and they add color and design. In short, they control page topography and in essence become the page.

• WYSISYG HTML Editors
• Do-It-Yourself Tables
• Table Width and Cell Width Considerations
• Table Column Span Considerations
• Tables as Design Elements
• Table Borders and Backgrounds
• What's a Developer to Do?

At the same time, tables can be pesky and irksome. While it is sometimes easy to get lost in nested tables, the real culprit is the browser. Netscape, Microsoft IE browser, and AOL's browsers interpret table structure differently.

This article focuses on some techniques a developer might use to create tables that perform the same across major browser brands. It is absolutely essential that, as a developer, you test pages with not only in Netscape and IE but also on PC and MAC platforms. If you don't have the capability in house, then find friends or colleagues who have different computers.

Graphical editing programs strongly support structured tables, and I can understand the complexity of the program in attempting to parse images and objects into an orderly table. However, that structure tends to be bulky and contain far more cells than needed. Experience has shown me that the more I rework a table in a graphical editor, such as adding, deleting, and changing table cells, the more confused the table code becomes. In a short while, I find artifacts (left over code fragments) all over the place, and the table cell parameters like height and width are often in conflict with other cells.

The solution? Plan ahead. Using an image creation tool, such as Adobe Photoshop or paper and pencil, I draw the table constructs with guides or lines. While this may seem archaic, I even use colored pencils to indicate nested tables. Whether it is a graphical editor like Macromedia Dreamweaver or a graphical assisted editor like Allaire HomeSite, the key is planning and preparation. Those two things never change.

An example that comes immediately to mind is cell width, cell padding, and spacing. The most common problem is in the table tag itself. If you want a well-structured table, do not simply use <table>. It is better to specify all the major parameters, such as <table border="0" width="600" cellpadding="0" cellspacing="0">, because the browser default values are not "0" as one might expect.

Many Web sites have nice lines and rounded corners to accentuate text and images. This is all well and good but you can easily see the difficulty caused by the interpretation of various browsers.

The following effect can be created in a variety of ways. With that stated, here I am using table cells to combine images and text. The problem, as can be seen, is getting the images to line up where you want them in both Netscape and IE browsers. (Hint: When creating straight lines, as shown in Figure 1, I used a colored 1x1 pixel GIF image, and stretch it by using the height and width parameters of the image tag.)

All four images were created using the same HTML code. As you can see, the table border is turned on for the lower image in each group to show how each browser interprets the table code.

In the table code, the cell widths are unspecified and you can see how the table appears. It is hard to observe, but the first table data of the Netscape view is collapsed and the curve-shaped blue image does not meet the horizontal line. The IE browser view more closely resembles what we want. However, in some earlier versions of IE, the lines also do not come together.

To achieve what you design consistently, you must specify the table width and each of the table cell widths. If the numbers don't add up, then the table structure is once again left to chance. With good design, the tables will appear the same in both browser types. (You can see this example in operation at www.ehouseloans.com.)

Okay, so we learned our lesson about specifying table cell widths. Or did we?

In the next example, we have a table where the first and last table rows have a colspan="9", and in the second table row, each of the cell widths are specified and add up to the table width. Sounds like it should work. Using the IE browser, the table will appear as expected where the vertical red line on the right aligns with the end of the horizontal lines completing the box shape, and the cell widths are proportioned correctly. However, with the Netscape browser, we get the result shown in Figure 2 . (Image B has the border set to "1", so you can see the table structure.)

I had initially chosen to create the entire menu within a table structure to "containerize" it. However, the manner in which the different browsers interpreted the code foiled my objective.

There are several fixes to this situation, the most curious of which would be to insert a 9-cell row ahead of the row which has the colspan="9". In this new row, keep all the cells empty and set each of the cell widths to the desired cell width value. Ultimately, in the interest of minimal code, I chose to divest the table of the horizontal red line images and place them ahead and behind the table structure.

By using the border and background attributes of table and cell parameters, we can create wonderful page topography without the burden of large image files. However, as Internet bandwidth increases and connect charges decrease, file size will become less of a consideration in Web page design.

These last two examples show that by using tables and one-bit images, a designer can create interesting structures. In the application of the above menu example, I used style sheets to remove the underscore from the anchor tags and the anchor pseudo "hover" style to create the appearance of a mouse-over effect. While the hover effect only works with IE browsers at present, I hope that Netscape will employ this in future versions. (You can see this in operation at www.shorelinearts.org).

In case you're wondering, yes, the whole menu system could have been created as a graphic and an image map used for the links, or a group of images with mouse-overs. In this application, the client anticipated changes and expansion in the future, and to reduce costs for this non-profit organization, we chose to take the style sheet approach.

I should mention that with the rapid development of browsers, HB Graphic's basic philosophy is that our designs work best in the latest version browsers, they work correctly in version 4 browsers, and they won't break version 3 browsers. I also try to take advantage of the little extra things supported in IE browsers where they enhance the page but are not essential in creating the desired page effect and performance.

Nowhere else have I experienced such a divergence in HTML code interpretation than in table tag attributes. The mere act of adding color via table, border, or cell attributes can create a variety of patterns (see Figure 3).

In the examples shown, I used a table to create the outer border and a 6-celled table to create the inner letters and numbers. A little quick math indicates there are 81 different ways to construct these tables using combinations of table, border, and cell color attributes.

Each column, containing two table images, is created using the same code. However, each browser displays the corresponding images differently. The six shown here should give you good reason to check your table designs in more than one browser. I hope that Microsoft and Netscape will reach some accord about table tag interpretation in the future. Is that too much to hope for?

To test the images on your browser, click here to open a pop-up window.

I don't think there is a way around these problems except by good design practices. Even with the latest releases of the browsers, I expect that the situation will not improve much. Maybe the next generation of fully capable XML (Extensible Markup Language) and XSL (Extensible Style Language) browsers will show compatibility in code interpretation.

Pesky tables or not, they are still an excellent building block for creating feature-rich Web sites. Use them wisely and profit with good-looking, fast-loading Web pages.

About the Author

Al DiMarzio's career and business interests in computing technologies, marketing, and publishing span more than 40 years. In a lifestyle change, Al left the corporate world and formed HB Graphics. The company, primarily desktop publishing, moved quickly into Web publishing in 1995 and grew from static HTML to interactive, data-driven Web sites.

Al received a BSEE and MSEE from Northeastern University and has completed corporate and post-graduate studies. During his tenure in engineering R&D, he received three patents. He has authored more than 50 articles and reports on computing technology, business management, and marketing, and has conducted seminars on the same topics.

Al can be reached by email at dimarzio@hbgraphics.com, and his Web site is accessible at http://www.hbgraphics.com/.