[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev Tables: getting started
lynx-dev Tables: getting started
Wed, 17 Nov 1999 10:45:05 -0500 (EST)
assuming the basic 1-pass parse by Lynx, how could it handle tables
to create something tabular & corresponding to authors' intentions?
i am assuming (following KW) that TRST is usually inadequate for this.
the first step is to focus on normal tables with good HTML:
problems arising from less well-composed HTML can be dealt with later.
to achieve this distinction, users need to have an option
to switch to TableSoup mode when they see a table they want improved.
my starting picture is a choice of compiling support for TS or not,
with user's options in lynx.cfg & `o'ptions to make TS active.
to show the user that there's a table present (when TS is active),
Lynx would render <table> & </table> on-screen:
<table> would appear as a link labelled eg `Start of table';
</table> would not be a link, but appear as eg <b>End of table</b>.
in TS mode, if the user wanted the table re-rendered with TS,
s/he would follow the link with a result similar to a frame link:
the HTML between the link & the next `End of table' would be re-rendered
& presented as a separate document (details below);
if tables were nested, the process might be repeated,
but that's a problem which can be addressed at a later stage.
the user could read the table, save it or return to the previous page,
esp if the re-rendered table were still a mess due to bad HTML;
there would be nothing to force users to have a table re-rendered
or to make TS active or even to compile it in the first place.
somewhere in the page created by TS for the table
there would be another link eg `Insert in document',
following which would cause Lynx to insert the re-rendered table
back into the larger document in place of the section
between `Start of table' & `End of table' (inclusive).
once upon a time, all this would have been scarcely thinkable,
as Lynx would have had to go get the source all over again,
but now source-cacheing is available & would be recommended with TS:
all Lynx has to do is find the right section of the source to process.
to process a table -- we're assuming the HTML is not badly invalid --
Lynx would concentrate on the tags <tr> <th> <td> + closings,
ignoring <p> <br> or anything else which might upset formatting;
it would use < ... width=n% > & -width to calculate how many columns
to allow for each <th> <td> , wrapping text/numbers when necessary;
instructions to centre/justify would be followed, insofar as possible.
yes, the details of this would need some trial & patient improvement,
but it should be remembered that when in TS mode (by user's choice)
Lynx can make as many passes thro' the HTML as it needs
without affecting its ability to render other documents quickly.
i estimate that it would take me a couple of months' serious study
to revive my lapsed C, learn how other people program in it
& get a thoro' enough knowledge of Lynx innards
to start to create useful feature patches. the rule here is always DIY,
but that's no reason not to try to stimulate other people's thinking.
what we should never do is simply assume something is too difficult,
esp if it can be broken into a step-by-step process.
SUPPORT ___________//___, Philip Webb : address@hidden
ELECTRIC /]     | Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto
- lynx-dev Tables: getting started,
Philip Webb <=