lynx-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV LYNX: please say "THIS IS A TABLE!"

From: Rob
Subject: Re: LYNX-DEV LYNX: please say "THIS IS A TABLE!"
Date: Fri, 27 Mar 1998 19:29:20 +0000 (GMT) 
Larry W. Virden, x2487 wrote:
> 
> Is it possible to perhaps color code particular columns?  If for instance
> columns alternated colors X and Y, that would seem to make it a bit easier
> to read the columns.

I think I could possibly hack something like this into my stylesheet code
over the weekend - I'll try this on sunday night/monday day, see how it
goes.

> I suspect this is all part of the general "we hate the way columns look
> in lynx" syndrome.  I keep wondering if perhaps there is a better way
> to do this.  One thing that was mentioned at one point was if some brave
> lynx knight stepped forward to take on the dragon of tables, that they
> might modify the parsing code to start doing a 'look ahead' type cache
> when the table tag is encountered - reading all of the code up to the
> close of the table (handling embedded tables appropriately), identifying
> the number and max width of said columns, then 'unget'-ing the input, making
> it appear to the rest of lynx as if the code were never read.  Then,
> in the actual table processing, one would know the number of columns,
> and max width of each column.  

personally, I'm working on a object screen management layer on top of curses 
that handles things by not rendering to the screen, but rendering when things 
need to be displayed.  hmm, that's probably too vague a description.  an 
example!

    <html><head><title>Title</title></head>
    <body><h1>H1</h1><h2>H2</h2><p>some <b>bold</b> text</body></html>

you get a tree of the document like (as linked lists)

html
|
head----body
|       |
title   h1---h2---p
(Title) (H1) (H2) T(some)
                  b(bold)
                  T(text)

this is rendered depth first, so you rendered the "<b>bold</b>" into a
holding area, then the "some ... text" around it, until you've rendered
the <html> which you then display, wrapping things as you go.  this
isn't an ideal method, requiring the full parse tree to be held in
memory (ie the whole document has been downloaded) before you even start
to display anything on the screen, but it has some advantages over the
current lynx method - it lets you change the size of the screen and
rerender easily, it gives you the inheritability of elements that you
need for real style sheet support, and it lets you do cute things like 
making elements (and their subtrees) visible or not (a la dynamic html).

it helps with tables as well;

    <table>
    <tr><td>this is some text</td> <td>a <a>link</a></td></tr>
    </table>

as you render up the document tree, you know the size of all the subtrees
(by keeping track of this at nodes), so you can size your table appropriately.
when you come to render the table (by traversing the tree linearly), you 
know in advance how big the table is, and how big each column is.

I haven't been working on it anywhere near enough recently, but I'll have
another look and make sure I wasn't hallucinating when I dreamed up this 
scheme...

> Unfortunately Arthur and the round table appear to be off fighting other
> battles, leaving lynx to stand alone in front of this as well as the other
> major dragons (XML, Style Sheets, Java, JavaScript, ...)

*guilty as charged* (assuming I'm part of the round table...)
reply via email to
[Prev in Thread] Current Thread [Next in Thread]