There's one other possibility, which is that VALIGN would be ignored if no
HEIGHT attribute was specified anywhere in the row, otherwise the contents of
any cell with VALIGN would be aligned according to the maximum HEIGHT value,
which may in fact be less than the formatted height of the row (or even of the
cell). This is of course a compromise between lawful good and chaotic evil.
The last time I looked at the table support in XMosaic, it was in pretty sad
shape. It did not even conform fully to the HTML+ model, to say nothing of the
HTML3 model. Perhaps it has been improved since then.
So what is the ruling on the WIDTH and HEIGHT attributes of table cells? Are
they suggestions which should be verified by the browser, or is the browser
to treat them as absolute values? If the latter, what should the browser do
when the actual contents of a cell exceed the width or height? Chop it off?
Let it overflow the cell? What?
There's a major problem with specifying WIDTH and HEIGHT on a table cell, which
is that the author cannot accurately predict the formatted width and height
of a cell. This is because the reader (end user, consumer, whatever) might
specify a really big font, or have a style sheet that adds lots of vertical
white space, or what have you, which would throw off the author's carefully
calculated WIDTH and HEIGHT values. This would not be so bad if WIDTH and
HEIGHT were mere suggestions.
I still think that VALIGN is a bad idea. Nested tables I can live with.
Michael Johnson
Relay Technology, Inc.