Re: lynx-dev Centering in Tables

[Chuck Martin]

On Tue, Aug 03, 1999 at 05:42:02AM -0500, Klaus Weide wrote:
> 
> I think "lynx is doing it wrong" is too strong.  Lynx doesn't yet have
> any way to treat tables in tabular form.  As long as there is this basic
> limitation, there is no way to apply ALIGN attributes on TD and TR in
> the way they are intended.

This is true.

>                             There also is no way to apply the ALIGN
> attribute on TABLE in the way it is intended, since lynx doesn't create
> a rectangular block that could be shifted left or right as a whole.

This is also true, but I don't think aligning things on on a line-by-line
basis that were intended to be applied to that rectangular block is a
logical or usable substitute.

>                                             It is possible that yes,
> some tables improve by changing line alignment handling, but other pages
> with tables may well look better the way things are done now.

Do you know of any examples (real or contrived) that would look better
with the current handling?

>    1997-05-21
>    * Mods in HTML.c and LYCharUtils.c so that TABLE blocks are treated
>      as divisions in the DIV nest, with a default alignment of HT_LEFT
>      if the TABLE start tag lacks an ALIGN attribute, and otherwise,
>      that attribute's value.  Nested TABLEs extend the DIV nest.  This
>      avoids the problem in the vanilla code of TABLE content inheriting
>      the alignment of a containing CENTER or DIV which is intended for
>      alignment of the TABLE as a whole.  Also added support for ALIGN

This is certainly a good point, but I think a better way of avoiding this
problem would be to ignore the ALIGN attribute in <TABLE>, since there
really isn't a table to align, and let the <TABLE> element imply a
<DIV ALIGN=LEFT> for all table content that doesn't have an overriding
ALIGN attribute.  After all, the ALIGN attribute in a <TABLE> element
serves the same purpose as a containing <CENTER> or <DIV>, which means
that the current handling has the same problem Fote was trying to avoid.

>                                                Any proposed "better"
> approximation meant for general use should work well (or at least, not
> worse than before) for a variety of pages though, not just for a few
> selected tables that someone is interested in.

I think what I proposed above would do that.

> there is also a curious thing under "Inheritance of alignment
> specifications" (in 11.3.2):
> 
>    The order of precedence (from highest to lowest) for the attributes
>    align [,...] is the following:
>     [ 1. - 4. snipped ]
>     5. An alignment attribute set on the table.
>     6. The default alignment value.

This is certainly confusing.  It doesn't seem to make sense, and I wonder
if it's an error.  In any case, I think it would be best to ignore item
5 in that case, because it seems to do more harm than good.

Chuck