Re: lynx-dev Centering in Tables

[Klaus Weide]

On Tue, 3 Aug 1999, Chuck Martin wrote:
> 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.

Logical - maybe not very.  Usable - well lynx has been using it for
quite a while, and while some people have proposed changing it, there
wasn't a general outcry.

One can also say that lines get wrongly aligned anyway if you don't apply
ALIGN attributes - it's just alway "LEFT" alignment.

> >                                             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?

- Tables where each row has only one cell.  Or maybe just one "significant"
  cell - the others being just a spacer or bullet etc.
- Simple tables which happen to already be in a "tabular form" because the
  columns already align (corresponding cells have the same lengths, or
  nearly the same lengths, perhaps by accident).
- Other simple tables may benefit from centering: they become somewhat
  easier to scan vertically because the differences in horizontical
  positions are smaller.  Compare
  
     foo bar baz
     looongfoo loooongbar looongbaz

  with

                                 foo bar baz
                        looongfoo loooongbar looongbaz

  I find it easier to see that "baz" belongs to "looongbaz".
  (Of course if this alone is a good reason then we should center all
  table lines...) 

- Tables with whole paragraphs (multiple lines) or other blocks and longer
  stretches of text per TD.  Each such "cell" is not rendered as a cell
  by lynx, but its content gets the specified alignment.
- Don't think only of centering, but also ALIGN=RIGHT.  This case may
  strengthen some of the points above (because the effect is more
  pronounced) - or not.

Well, better is a matter of taste.  In some of the cases it may look better,
and in some it may get closer to the author's intentions, and in some the
two may actually coincide. :)

I am just giving you some arguments, it's not that I believe strongly that
things should stay as they are (although, after drawing up the little list
above I find there may be more reasons than I thought).  But basically,
you don't have to convince me, you have to convince Tom...

> >    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>

... if we decide to ignore that curious "Inheritance" thing from HTML 4.0 ...
(otherwise there is an additional purpose).

>                                                             which means
> that the current handling has the same problem Fote was trying to avoid.

On the whole, your argument makes sense.

> >                                                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.

So are you willing to make some patches, run lynx with them for a while
(browsing various kinds of sites), then convince the lynx-dev readership
(and Tom) that this is better, and that they should try it themselves?

> > 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.

I chose to interpret it in the sense that the ALIGN can have both effects,
for TRST (when individual cells *can* get aligned).  But it's certainly
questionable.


   Klaus