Re: More HTML3 DTD

If Carl thinks it will be easy to implement VALIGN in table cells, then he is
overlooking something. It would be easy *IF* you assumed that the maximum of
any HEIGHT attributes in a row was in fact the maximum height for the row,
which may not be a valid assumption. If on the other hand you assume that any
cell could be taller than the maximum HEIGHT attribute specified in the row,
then you would have to actually format the contents of each row (without
producing any output) in order to determine the maximum height, THEN go back
and actually produce output, this time with the appropriate maximum height
plugged in. That's a pain in the ass, and almost doubles the time required to
format a table.

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.

Received on Thursday, 1 December 1994 14:39:26 UTC