On Mon, 8 Nov 1999 21:35:43 -0500 (EST), Matthew Orgass wrote:
>On Mon, 8 Nov 1999 mcmahill@mtl.mit.edu wrote:
>> On 8 Nov 1999, Nathan J. Williams wrote:
>> > That said, I'm going to get back to futzing with this, hopefully
>> > making a more non-table-happy version. Someone in this thread talked
>> > about making tables that render gracefully as non-tables; I'd
>> > appreciate suggestions on practical ways of doing that.

That'd be me.  One thing that I'd run into when experimenting with various
browsers was this Evil Hack:
<TR><TD>data</TD>&nbsp;&nbsp;&nbsp;<TD>other data</TD></TR>
or
<TR><TD>data</TD><PRE>   </PRE><TD>other data</TD></TR>

In the browsers that support tables (the few I tested) the stuff outside
the actual cells was ignored, but got rendered by non-table-aware
browsers.

I'm really wary of putting this in a production page though.

>> if its a server side hack, I'm not too thrilled because if you grab a
>> snapshot of pkgsrc you might want to follow the README.html's on your
>> local machine, ie file:// URL's.  If it can be done in HTML, I'm ok with
>> it.
>
>  On non-table browsers the document is rendered as if the table tags were
>not there.  So relying on alignment with a header line (especially when
>there are empty cells) or (even worse) relying on multiple lines (<BR>,
>lists, etc.) within <td> tags matching the same lines in the next <td> tag

It's a bad idea to rely on multiline alignment even with table-aware
browsers.

>can cause problems.  If you use one <td> tag per line and fill in every
>cell with a visible character then it is at least possible to read it on a
>text browser. It is text browser friendly if you do not need to count
>cells to find out what a given value means (or there are only a few
>columns).

Stuff like putting 'n/a' or '--' in otherwise empty cells can help.
--
T. M. Pederson
salvage@galaxy.plethora.net