lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Centering in Tables


From: Klaus Weide
Subject: Re: lynx-dev Centering in Tables
Date: Tue, 3 Aug 1999 05:42:02 -0500 (CDT)

On Mon, 2 Aug 1999, Chuck Martin wrote:

> I have a question for those who know the ins and outs of HTML regarding
> lynx's determination of when to center.  It seems to me that if there
> is an "ALIGN=CENTER" attribute in a <TABLE> element, this refers to the
> placement of the table itself rather than the text within the table, if
> I'm reading the specification correctly.  An ALIGN attribute in a <TD>
> element, however, would refer to the text in a cell, and an ALIGN attribute
> in a TR would provide a default alignment for all cells in a row that
> don't specify the alignment explicitly.  If there is no ALIGN attribute in
> either the <TR> or <TD> elements for a cell, it should default to left
> (or possibly a default that was specified outside of the table - I'm
> unclear on this).  It should under no circumstance default to what was
> specified in the <TABLE> element, because that refers to the table itself.
> Am I correct?  If so, lynx is doing it wrong.  Comments?

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.  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.
As long as table handling is as minimal as it is, there are only
choices about whether and how to align individual lines that result from
the table's content.

So I assume that with "lynx is doing it wrong" that, even within the
limited current methods, things would be improved by handling (or not
handling) ALIGN attributes different.

You may well be right.  Others have questioned this lynx behavior before.
See <http://www.flora.org/lynx-dev/html/month0599/msg00034.html>, there
is even a small patch in that message.  You (and the author of that
message) may well be right.  I am just not convinced, or at least not
convinced enough to champion such changes.  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.  Fote
changed the alignment handling to what it is now (at least I don't think
we have changed it too much since then):

   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
     attributes in TR elements.  If the TR has no ALIGN attribute, it
     inherits that of the current division, which should be that of the
     current TABLE.  This, of course, still does not yield true TABLEs
     for truly tabular content, but makes TABLEs used for formatting
     more readable. - FM

I tend to assume that there were some reasons for the deliberate
handling of ALIGN in that way, that I am just not aware of.

I may be completely wrong, and you are free to experiment with
changing it (as ke did in the URL above), and share your experience.
There is no completely "right" way, as long as tables are not rendered
in tabular form, and possible ways to handle alignment (or not) in the
current framework can only be approximations.  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 ran into this question in the context of TRST code, but won't get
into that here.  Not only because it doesn't make much sense to
discuss unfinished code you haven't seen yet;  since TRST deals ony
with "simple" tables, it still makes sense to discuss alignment for
tables in general, and this can (and should) be done without regard to
TRST.  (Don't worry how changes may effect TRST.)

   ----

HTML 4.0 says that an ALIGN attribute on the <TABLE> tag "specifies
the position of the table with respect to the document" (11.2.1). But
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.

So item 5 in this "cascade" seems to say that, indeed, a TABLE's ALIGN
attribute can determine the alignment of cell contents.  That's at
least how I interpret it.


    Klaus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]