lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev [yet another] note on table rendering


From: pAb-032871
Subject: lynx-dev [yet another] note on table rendering
Date: Thu, 27 Apr 2000 00:02:36 -0700

I've been reading previous notes about table rendering.  It got me
started with a few questions, and some ideas.  Please note that I'm not
a programmer, so this is all theory and not much concrete help.

I have learned a bit about the theory though.

First, Lynx is a text-grid/text-cell based browser, and table data is
often given in pixel values, or a percentage of window size.  How would
Lynx convert these values -- treat each 10x10 pixels as 1 character, or
take window font into account?  A flat, 10x10 interpretation seems
faster, and less trouble to code.

Percentages would be fairly simple, I think: take the current window
size and round percent to the nearest char width/height.  <TD WIDTH=###%
might be difficult though, because it's a nested value [inside the
WIDTH= value, if present, of the entire table].

Even if support for tables is never implemented, Lynx should learn how
to handle the tags a little better.  For example, it could treat <TD>
tags as <BR>, and <TR> as <P>.  This would be a great idea, even if
nothing else in this message is.  In the same way, it could treat
<TD ALIGN=[left/right/center]> as <BR CLEAR=[left/right/center]>  You've
seen what some table-laden pages look like in Lynx. . .

Maybe the current version already does this.  I don't know because I'm
using a v2.7.1 port.


Lynx was designed as a one-pass browser, but here's some thoughts on
making it emulate two-pass/multi-pass rendering.  I know I'm repeating a
few things from previous messages, but hopefully I'm going somewhere
with this.

I should really put this in point-form:

1)- Setting its behavior in the Options menu.
2)- Different screen displays, based on the chosen rendering option.
3)- Lynx's actual behavior in response to table data.


1)- How about a simple row of radio buttons in the Options menu?

    (*) Ignore tables. [default?  Default settable in lynx.cfg?]
    ( ) Add checkbox at top of document, Reload to render whole page.*
    ( ) Also add checkboxes beside tables, Reload to render selected items.
    ( ) Render tables automatically.  Checkboxes beside nested tables.
    ( ) Render all tables automatically.

*This option would NOT load nested tables, but maybe the checkbox could be
 repeated in the reloaded doc, indicating that nested tables exist.


2)- The different displays.

Ignore Tables would be pretty much what you see now, so I won't bother.

If a table is chosen and rendered, it could be drawn out in dashes and
bars [if BORDER=0 is not specified in the document].  I don't like the
idea of creating a new page, as is done with [USEMAP] areas, but this
might be the only way to make it work.  If so, it could create a [TABLE]
link instead of a checkbox, the same as it does with [USEMAP]s.

And while I'm on the subject, why can't it treat [USEMAP] as an unordered
list, within the page?  Or maybe as a small form , consisting of a SELECT
popup and SUBMIT button?


    (*) Render all tables automatically.

o-----------------------------------------o
| Header cell one    |  Header cell two   |
|-----------------------------------------|<TD COLSPAN=2 ALIGN=CENTER>
|                                         |
|            Something centered.          |
|          I think the default is         |
|           VALIGN=MIDDLE if not          |
|               specified[?]              |
|                                         |
|-----------------------------------------|
| o----------------o | o----------------o |
| | Nested table   | | | Damn   |       | |
| | [These get     | | |----------------| |
| | tricky]        | | | Another one... | |
| o----------------o | o----------------o |
o-----------------------------------------o



    (*) Render tables automatically.  Checkboxes beside nested tables.

|                                         |
|-----------------------------------------|
| [ ] RENDER         | [X] RENDER         |
|                    | Damn               |
| Nested table       |                    |
| [These get tricky] | Another one...     |
|                    |                    |
o-----------------------------------------o


If adding a horizontal scrollbar is a problem, why not "squash" tables
that are too wide for the Lynx window?  Netscape does this if <TD WIDTH=
values are specified, but no <*TABLE* WIDTH= attribute is given.  I
don't know if this behavior is valid [probably not] but it might come in
handy.

They wouldn't need to be squashed vertically.


3)- Actual behavior.

When encountering tables in auto-rendering mode, Lynx could load the
page normally, then RELOAD it from the cache, using what it alredy knows
about the document and adding new information about the table[s],
imitating a second pass.  I don't know if it would have to create two
temp files for this or not: one being the actual HTML retrieved from the
server, and another being the following, recursively re-interpreted and
overwritten cache file.

For its own internal use, Lynx could put already-rendered tables inside
a PRE block to preserve white-space.  This would save it the trouble of
re-interpreting the same data over and over.

Avoiding endless-loop lockups when it tries to load a badly written
table might be tricky, especially if it's nested.  But if this is set up
right, it could just give you a "Bad HTML!!!" warning and render the
page as it would in "Ignore tables" mode.  I've noticed it gives up
trying to resolve an URL after 5 redirects.  Maybe it could do the same
with deeply nested/badly written tables.


Well, this letter is basically one long question mark.  If anyone has a
"!" to follow, I'd love to hear it.


                    Patrick
          <mailto:address@hidden>
 


reply via email to

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