[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>
- lynx-dev [yet another] note on table rendering,
pAb-032871 <=