Subject: Re: More HTML3 DTD Message-Id: <MICHAELJ.email@example.com> From: firstname.lastname@example.org (Michael Johnson) To: email@example.com (HTML discussion list) Date: Thu, 01 Dec 94 08:16:11 EST 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.