Re: Table Extension

Scott E. Preece (
Mon, 8 Jul 1996 09:15:23 -0500

Date: Mon, 8 Jul 1996 09:15:23 -0500
From: (Scott E. Preece)
Message-Id: <>
In-reply-to: "Solko, Dave's message of Mon, 8 Jul 1996 09:47:32 -0400
Subject: Re: Table Extension

| I've always wondered why tables wern't set up this way in the first
| place. If they worked this way, there wouldn't be as much of a rendering
| problem for non table-compliant browsers -- for the tables I create at
| least. While setting things up in rows instead of colums may be a little
| easier to visualize, IMHO, organizing in cols would be better. Maybe
| there should be something like this in Wilbur.

As far as I can see, all of the rendering problems for tables are
exactly the same whether you go row-wise or column-wise.  This isn't
surprising.  The real problem is that the data in tables is inherently
two-dimensional and HTML isn't.  Viewed the other way, HTML data is
inherently hierarchical and tables are doubly hierarchical - there is a
hierarchy in each dimension.  This creates havoc for, among other
things, inheritance of cell attributes (which really should be from both

Rendering engines have to re-construct that double hierarchy from the
single hierarchy that HTML allows the author to express.  I don't see a
palatable solution to this problem; certainly the choice of whether to
make the primary hierarchy vertical or horizontal make no real

[One interesting alternative would be to record tables cell-wise, with
the attributes of each cell indicating which row(s) and column(s) it
occupies.  This removes both hierarchical biases and makes inheritance
explicit in both dimensions. You could then have TC (or COL and
COLGROUP) and TR entries that were *just* carriers for header titles and
attribute inheritance. However, this form would be more trouble to work
with, more prone to errors, and no easier to render.]


scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail: