Matt no, the problem is not in the *number* of rows or columns. You are probably thinking about the situation where each Row starts with an identifier and then continues with column-cell-data directly related to that identifier. Fine, there's no problem with that sort of table.

The problem to which I refer is where each cell is an independent-datum, not tightly related to what row it's in, for example "List of important cities in California" might be a five-column wide table (let's say) and the row a city appears in, is not relevant to the city itself, and each row does not have an identifier simply because the entire table is just a "list" but in tabular form to save row-space.

That's a big run-on sentence. The table is not a data-table (like a programmer), it's just a "list" but graphically structured as a table, because a table is the most efficient way to show the data, while a list proper would take up many rows of space, mostly white-space, which is not efficient and looks poor to the eye.

Imagine a list like "Apples, Bananas, Cherries...... Zebra" with dozens of elements, but instead of being comma-delimited, it's all put into say a 6-column table just for beautification. Now add an element to the middle of the list somewhere. You *dont* want the edge of the row to extend further right, because that would be *ugly*. What you want, is everything to shift forward so that at most an extra row is created at the bottom, which would look normal, but not an extra column to the right which would look poor.

Will

**************It's only a deal if it's where you want to go. Find your travel deal here. (http://information.travel.aol.com/deals?ncid=aoltrv00050000000047)