ISSUE #1: WHAT CAN GO IN A TABLE CELL?
The more general answer (from a grammatical view) is a BODY element. That
approach is neat, orthogonal, and easy to verify. Of course, it also
allows for unbounded levels of nesting, and not just a single line of
nesting, but branched (tree-shaped) nesting: tables within tables, where
each cell of a given table can contain a BODY (including more tables).
That's no great shakes for a parser, but it's going to be tough on the
current generation of browsers, not to mention editors (my own area of
interest). HTML 2.0 documents readily render in a linear fashion, but
indefinite levels of nesting within tables can cause some not-so-minor
headaches in resolving just how large a given cell will be and what impact
that will have on its associated row and column and formatting for all the
affected cells. (I speak as someone who spent many, _many_ hours debugging
table-resizing behavior.)
[Sidebar: This approach does suggest an intriguing idea: think of a
browser that can also behave a bit like a Mandlebrot viewer, where you can
zoom into and out of levels of data within a single HTML document (in
addition to linking to other documents). You can maintain the "one screen
view at a time" for a given HTML document, yet have more detail cached
locally. (A similar approach might work for footnotes, but that's another
discussion.)]
If the answer _isn't_ "a BODY element", then you have to enumerate
conceptually what will and won't be allowed in a TABLE cell. This shifts
the problem from the technical realm--how to edit and present indefinite
levels of nesting--to the political realm--who decides what is allowed and
what isn't. (To quote G.K. Chesterson, "Art, like morality, consists of
drawing the line somewhere.") Technical issues must then balance with user
demands and requirements: too complex a solution will take too long to
implement and will violate the guiding principle of keeping HTML simple;
too simple a solution will drive the customers to seek more powerful
proprietary implementations and will undermine adherence to an open
standard.
Compounding things further is the question of multiple elements within a
given cell and nesting within those elements that allow nesting. Is an
indefinite number of elements allowed within a cell? Are there any
useful/meaningful/necessary constraints on the mix and ordering of
elements? If nesting elements are allowed, are there limits to the level
of nesting.
An additional axis in all this is grammatic complexity, i.e., how easy is
it to verify that a table is well formed or to block creation of a
malformed table. This is where the BODY proposal starts looking good again
(except, possibly, to those who have to render such tables for editing
and/or browsing purposes).
This message is already a bit too long, so I'll post a second one
discussing some possible implications of including specific HTML elements
within table cells. ..bruce..
--------------------------------------------------------------------------
Bruce F. Webster | The thought that life could be better
CTO, Pages Software Inc | Is woven indelibly
bwebster@pages.com | Into our hearts and our brains.
http://www.pages.com | -- Paul Simon, "Train in the Distance"
--------------------------------------------------------------------------