lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev new tables idea for SoCR


From: Heather Stern
Subject: Re: lynx-dev new tables idea for SoCR
Date: Thu, 15 Jul 1999 10:11:16 -0700 (PDT)

Lloyd G. Rasmussen wrote:
> Unfortunately, Home Page Reader, from IBM Special Needs Systems, is not
> open source, but a big executable for Win95/NT.  Maybe I can extract part
> of the documentation for you.  The basic idea is that it provides a method
> for moving around within a table, hearing a cell at a time, probably
> prefixed by the row or column header.  They tried to follow the HTML 4.0
> spec as much as possible.  This is probably only one of two good examples
> right now.  The other example is the W3 browser running in Emacs, with T.V.
> Raman's emacspeak extensions.  

The closest equivalent to this in lynx' paradigm would be to see the table,
only render cell pointers as [cell n.n], then people would have to hotlink 
the cell in order to have its contents rendered (whether tiny or large and 
freeflowing).

Braille readers might love it.  I say "yuck!"  Come to think of it I think
they'd hate a great field of the words 'cell' over and over again:

Um, marginally better than that would be to have [table] and hotlinking
the table would spread it out like an ISMAP link page, with only the 
first line of any particular cell (ellipsed off if it's much longer of 
course, so people can tell it's worth linking the cell further).  This
sounds much closer to my "couldn't we render it as a funny list?" idea
from awhile back.  Only I never thought of the ismap context.  Hmm.  The 
idea in my head sounds kinda nice, maybe we could do it this style, including
the ellipse-effect for long lines, inline to the document.

I'm afraid that all sounds terribly obtuse, so I'll draw the same samples
as last time, this style:
...example #1

Caption: Possible CAPTION
cell 1.1: A paragraph ho hum de dum.  A whole lot more A stuff.  Wraps as...
cell 1.4: B paragraph ho hum de dum.  Thanks mr.B.  Wraps as necessary of...
cell 1.5: C paragraph ho hum de dum.  A whole lot more C stuff.  Wraps as...
cell 2.1: D paragraph ho hum de dum.  More D stuff.  Wraps as necessary of...
cell 2.2: E paragraph ho hum de dum.  More E stuff.  Wraps as necessary of...
cell 2.3: F paragraph ho hum de dum.  More F stuff.  Wraps as necessary of...
cell 2.4: G paragraph ho hum de dum.  More G stuff.  Wraps as necessary of...
cell 2.5: H paragraph ho hum de dum.  More H stuff.  Wraps as necessary of...
cell 3.2: I paragraph ho hum de dum.  More I stuff.  Wraps as needed of...
cell 3.5: J paragraph ho hum de dum.  More J stuff.  Wraps as necessary of...
cell 4.1: K paragraph ho hum de dum.  A whole lot more K stuff.  Wraps as...
cell 4.3: L paragraph ho hum de dum.  A whole lot more L stuff.  Wraps as...
cell 4.5: M paragraph ho hum de dum.  A whole lot more M stuff.  Wraps as...
cell 5.1: N paragraph ho hum de dum.  A whole lot more N stuff.  Wraps as...

...example #2

Caption: Tabular info for ya!
Hcell 1.1: Name of recipient
Hcell 1.2: Award Recieved
Hcell 1.3: Date of Award
Hcell 1.4: URL
cell 2.1: lynx-dev team
cell 2.2: Best of Linux at DaveCentral
cell 2.3: July
cell 2.4: http://big-long-URL-here.com/unless-its-so-long-it-falls-off/inde...
cell 3.1: joe random webmaster
cell 3.2: cool site of the day
cell 3.3: yesterday 
cell 3.4: http://shorter-URLs.com/can-be-hot/index.html
cell 4.1: (etc. ad nausea)

Conveniently, enclosed tables could be given whatever level of distance is
normal for DL lists.  "cell n.n" is the hotpoint, and will take you to the
rest of the cell - preseumably be rereading the source but this time only
rendering the desired cell.  Could be very bandwidth wasteful.

Um, anyways I don't like this as much because it doesn't -look- like a table;
on the other hand, it is very readable.  

* Heather

reply via email to

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