-- GENERAL ISSUES --
There will be a natural tendency to state that the end of a given table cell
closes all tags opened within it. That is correct behavior, though the Puritan
side of me resists making that a feature of the spec; I am leery of
grammatical shortcuts.
Also, this posting doesn't address the issue of how many elements are allowed
in a table cell or in what direction the table grows to accomodate a given
element (or collection thereof) in a given cell.
-- ANCHOR ELEMENTS --
ANCHOR: relevant only as applied to some other element inside the cell, though
it may be the outermost tag set.
-- BLOCK FORMATTING ELEMENTS --
ADDRESS: certainly acceptable, though it raises some formatting issues
BODY: make the most sense if each table cells contains exactly one BODY
element, but that raises its own set of problems.
BLOCKQUOTE: same as ADDRESS
HEAD: prohibited (see HTML)
HEADINGS: I could argue this one either way; prohibition would make things
simpler, but I can see a heading in a wide column or a joined rows of cells.
HORIZONTAL RULE: depends more upon other factors, viz., if there is some way
of setting row and column borders for the table.
HTML: one could argue making each cell an HTML document (the BODY solution
taken one step further), but that would probably only make sense given a
"Mandlebrot browser" solution. Otherwise, not much point to it.
LINE BREAK: necessary
PARAGRAPH: necessary
PREFORMATTED TEXT: probably necessary; in fact, it can provide a mechanism for
explicitly setting cell width
TITLE: prohibited (see HEAD)
-- LIST ELEMENTS --
This is an all-or-nothing proposition: either all list elements are allowed
within a cell, or list elements are banned altogether.
-- CHARACTER FORMATTING ELEMENTS --
Necessary.
-- IMAGE ELEMENTS --
Very useful and probably necessary.
-- FORM ELEMENTS --
The focus of a lot of current discussion. It certainly makes sense for a table
cell to contain a (single?) <FORM>...</FORM> element. It also makes sense that
FORM elements contain TABLEs. If both are allowed, then we're back to the
indefinite tree branching mentioned in an earlier posting. I'd vote for
allowing one or the other, but not both.
-- TABLE ELEMENTS --
Good question. I could argue that nested tables is the simplest mechanism for
creating tables with cells of varying widths and heights. For example, suppose
I want to create a table that looks like this:
----------------------------------
| |
----------------------------------
| | | |
| -----------------
| | | |
----------------------------------
This could be implemented as a 2-row x 1-col table; embedded within the second
row is a 1-row x 2-col table; embedded within the second cell of _that_ table
is a 2-row x 2-col table. That's probably a whole lot easier than to specify
this as a single 3-row x 4-col table with certain cells merged.
The problem: what determines the relative widths of the cells? The contents?
User-specified values (e.g., WIDTH="40")? This leads into another discussion,
best left for another posting.
I hope I haven't unnecessarily retread old ground here; I'll appreciate
whatever feedback is there to give.
--------------------------------------------------------------------------
Bruce F. Webster | We hackers linger by our leading edge
CTO, Pages Software Inc | Forgetting what is pending in the cache
bwebster@pages.com | Till practice hurtles past us, and we crash.
http://www.pages.com | -- Jeff Duntemann
--------------------------------------------------------------------------