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

[Lloyd Rasmussen]

I agree that tables are a problem for Lynx.  As a blind user of the program, I 
mostly don't care whether I'm in a table or not, and would rather minimize 
extraneous information.

I find that tables such as the timetable or calendar previously discussed will 
be more readable in a GUI browser, because, with some patience, you can find 
out where each cell is located.  Lynx jumbles the cells together too much, 
especially when a table wraps onto additional lines.

The behavior of obeying <br> and some other tags within cells is useful. 

Lynx does a very useful service when you view pages like www.news.com, because 
it decolumnizes it for you.  Sites like this are not much fun in Windows with a 
screen reader because the reader cannot reliably separate the columns and let 
you just read the middle one where the news story is displayed.

In summary, as far as I'm concerned, I wouldn't change Lynx's behavior in 
displaying tables.

----------
>
> Re: announcing 'this is a table'
>
> I guess in reading along in this thread, I somehow missed the email
> that explained exactly what difference knowing one was seeing a table would
> make .  How is it different than looking at horridly written columns of
> text?  What difference in reading the data would one make?
>
> 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 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.  From there, one formats the columns so that
> text at least lines up properly in each column.  Of course, then there
> are those on the mailing list who have called for modifying lynx to
> enable the ability to place a 'scrolling window' (ala what you see in
> a one line text entry field) so that one could just move around the
> table data.
>
> 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, ...)
> --
> Larry W. Virden                 INET: address@hidden
> <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
> Unless explicitly stated to the contrary, nothing in this posting should
> be construed as representing my employer's opinions.
>