In the first installment of this series, I covered the basic concepts of how html table code works and how FrontPage writes html table code. It's very helpful to know this when you're creating page layouts. If you missed this article, I suggest you go read it now.

http://www.outfront.net/articles/tables1.htm

In this article, I want to go beyond the basics of a table with a certain number of columns and rows to a page layout table with cells that span multiple columns and/or multiple rows. I also want to discuss some of the ways you can avoid running into compatibility problems with Netscape.

Table Widths

You have the option of creating your page layout using percentages or pixel widths. It's more challenging to be precise using percentages. I will save that approach for a later article. We will focus on pixel widths today. There is always a debate over how wide to make your page layout. It used to be that most Web pages were optimized for low-resolution screens -- 640 x 480. It's much more common these days to optimize for 800 x 600 screens, but there is still logic behind the lower resolution approach. The primary one in my mind is that you don't have to worry about printer issues with the smaller layout.

If you choose to optimize for a 640 wide screen, then make your table 590 pixels wide. This will account for the left and right margins, which vary slightly in width from browser to browser. If you're optimizing for an 800 wide screen then make your table 750 pixels wide.

Do not drag and drop cell walls in FrontPage to adjust cell widths. This practice invariably results in math errors in your table code. It's important that all the cell widths in each row of your table add up to equal the table width. That's basic to guaranteeing cross-browser compatibility.

Colspans and Rowspans

It's best to plan your page layout by drawing a grid on a piece of paper. You can draw all the cells you need and estimate how wide they will need to be. I used to write my pixel widths inside each cell. It's ok for some of your cells to span more than one column or row. They can't span a half column or row, but they can span as many columns or rows as you like.

Count how many cells there are in the row that has the most cells. That will be the number of columns in your table. Count how many rows there are in your grid. With a page open in FP, do Table > Insert > Table. Enter the pixel for the table. Enter the number of columns and the number of rows. For now, go with a border of 0. If you're ever struggling with a table, set the border to 1, and view in the browser. This will often show you exactly what's wrong. You can go ahead and give this table a cellpadding of 10. Extremely precise tables use cellpadding and cellspacing of 0, but we will get into that in a later installment. Click OK.

If you look at the source code when you have finished creating your table, you will see something like this. <table width="590" cellpadding="10" cellspacing="0" border="0"> FP has written attributes into the table tag that constrains it's width to 590 pixels,
and puts 10 pixels worth of padding between cell walls and their content.

Now you have a table with cells that are not at all the widths you want, and no cells are spanning columns or rows. First we will work on the spanning issues. Then we will work on the widths. You merge cells to make one of the cells span more than one column. Just place your cursor on a cell. Click and drag across the cells you wish to merge to select them. Then do Table > Merge Cells. You can do that horizontally or vertically. Once I've merged the cells I need to merge, I usually select the entire table > right click in a cell > cell properties > set vertical alignment to top. That ensures that the content of any cell will stay at the top of the cell if the content in a neighboring cell gets longer than the content in that cell. Otherwise, the default is for the content to stay in the middle of the cell. That can look very wrong when you have a nav bar in one cell and lots of content in another cell in the same row.

If you look at the source code when you have finished merging cells, you will see something like this in the table data tags of the merged cells. <td colspan="3" valign="top"> That means that the cell spans 3 columns and the contents of the cell stay at the top of the cell regardless of the height of any cells in that row.

Cell Widths

Now it's time to do the math. You can select all the cells in a column > right click in the cell > cell properties > enter the width you want those cells to be. For any cells that span columns, just right click in that cell and do cell properties for that individual cell. Remember that all cells in each row must add up the width of the table. If you have width for each of the cells, and all the math adds up then your table will be just right in IE, and pretty close to right in Netscape. There are some tricks to forcing your cell widths to show up exactly the way you want in Netscape. I will go over those in a future installment.

If you look at the source code and find the cell tag from before, you will see it now looks something like this. <td colspan="3" valign="top" width=" 320"> FP has added the width attribute to the code.

Compatibility Issues

Netscape cannot see the cell height or table height attributes. If you lay your page out using cell or table heights, the page will almost certainly not look the way you want in Netscape. I will talk about ways to force rows to the height you want in a future installment in this series. Also, try to stay away from the style button in the table and cell properties dialogs unless you have planned for how your table will look in Netscape. The css code that FP writes when you use the table and cell style buttons often does not work in Netscape. Sometimes that's OK. If the page looks good in Netscape and your style treatment just looks better in IE, then by all means use the style. Just be aware that there are differences between Netscape and IE, and sometimes those differences are dramatic. Be sure to test in both browsers.

This overview of laying out a page allows you to understand the basics of creating a complex table. The next installment will cover ways to make force exact, cross-browser precision into each cell of your complex table.


Thomas Brunt
OutFront.net
A Microsoft FrontPage Learning Community