lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Tables in Lynx ...


From: Heather Stern
Subject: Re: LYNX-DEV Tables in Lynx ...
Date: Mon, 30 Mar 1998 21:39:43 -0800 (PST)

I ate the fortune cookie first, then read what these folks on lynx-dev wrote:
AB = Andrew Brennan (address@hidden)
PW = Philip Webb (address@hidden)
DC = David Combs

Oh, and apologies in advance for length ;D  I'm particularly interested in
comments from blind/screen reading users, and SGML wizards who know what
the DTD looks like today...

To summarize:
  People use tables for layout, actual tabular data, or a combination
  (which tables might really be well suited to).

  I have a number of ideas about what we could possibly do to tables all
  listed in one place, and highly favor the idea of giving people options
  regarding the rendering.  Some of my ideas may be harder to code than 
  others, but I tried to think of things that good ol' linear-parsing lynx 
  could probably do with minimum change.  I think.

> AB> I just compiled 2.8 to see if the table formatting had improved and in
> AB> one glance I can think of a potentially helpful modification.  When it
> AB> parses <tr> ... </tr>, wouldn't there be a benefit to imply a new line
> AB> or something to cause the next <tr> to begin on the next line??

What are the real reasons people use tables?
 1. Tabular data such as prices in columns.
    - Yes, this flavor of misbehavior would work.  I'll note when I first
    saw it use in MSIE (the version that came with the first rev of Win95)
    I considered it severely broken.  It caused some graphics diehards at
    my (then) company to begin to consider lynx viable, since it was clearly 
    ahead in cleanliness of rendering, all except graphics and that having
    reasonable alternate behavior for text mode.

 2. For screen layout of disjoint data.  
    - At least it's better than frames.  (Faint praise)
    Proper use of structure markup within cells would make this invisible -- 
    but as we must know by now, the cleanup behaviors of certain popular
    graphical browsers cause people to not bother with <P> and <Hn> markups
    as perhaps they should -- it looks fine to them.

    The fact that most authors write poor code shouldn't be used to penalize
    people who are trying to write good code.  Yet this is the meat of the
    thread -- how can people with lynx tell what the "layout" meant?

 3. For a different visual effect than one of the other list types.
    - Possible example

Big Heading Table Cell
Little heading     cell A1       cell A2       cell A3
                   cell A4       cell A5       cell A6
                   etc.
Little heading 2   cell B1       cell B2       cell B3
                   etc.

    TRs creating the only line breaks would ruin the sense of style here.

    In this case a DL rendering would be reasonable -- even possible,
    if the author used TH cells correctly.  (TH = DT, TD = DD, /TABLE = /DL)
    This would still tend to create line breaks, in fact would spend 
    considerably more vertical space on the rendering... but would be 
    possible in the first pass.  "normal" markup within the cells wouldn't 
    be ruined since DD sections can contain all normal markup (I think; 
    check DTDs for details).

If I were to create a lynx-clean table that would render to the graphic
world as 3.ex, I would abuse some <TD WIDTH="1%"> cells with either
<BR>_&nbsp;_ or _&nbsp;_ (where _ is space) as I desired. The blank 
content and slim cell request would render these as blank or decoratively
thin in GUIs, and as the splits where I want them in Lynx.  The results 
are quite vertically compact!  However, before 2.7.2 I was able to depend on 
lynx not rendering HTML it can't render adequately...

> AB> I was looking at a (poorly formatted) page that used five columns - it
> AB> had 4 with small icons (and no ALT tags) and a journal title.  The one
> AB> oddity I noticed was a line that appeared to have only three [INLINE]s
> AB> when the first of four was at the end of the previous line.  Seems the
> AB> modification should be rather simple, but it's been ages since I took
> AB> a look through Lynx's code.

Did they or didn't they write structure tags?  If they did, but missed one,
then it's a mere coding mistake, so as far as we can tell, they meant it
that way.

How much second-guessing can we do for an author before we are re-writing
their web page for them?  Is it worth the overhead that IE clearly suffers
in rendering time?  Whichever method we pick, will the user wish we picked
a different one?

> DC> What about a BLIND person?  How is he/she supposed to know
> DC> that the info should be mentally reorganized into TWO dimensional 
> DC> GROUPINGS
> PW> a valid point, surely.

Not being familiar with how screen readers parse before speaking, how do
blind-readers get DL lists read to them?  An e-contact of mine elsewhere
mentions that GUI browsers' rendering of tables is particularly bad for 
screen readers, they get something like

You are reading the left side of the | You are reading the right side of
page, because you are a Western kind | the page because you are an eastern
of person.                           | kind of person or a completist.

Imagine no pipes seperating and that all smashed together, then read one
line at a time.  Eww...
"You are reading the left side of the you are reading the right side of"

> DC> it could be an OPTION.

Perhaps we could offer "hint" attributes to tables writers, what should
lynx try to do with it?  It wouldn't fit the present DTDs -- but it seems 
to be how NS and MS got people willing to use some of their features.
Last I checked, misunderstood tags or attributes are still supposed to
be ignored completely, as if they're not present.

We could design lynx' usable ways of handling tables and allow web authors 
to optionally tag their tables as to which kind they are.  The user could 
have a key to select a default rendering type.

Oh, for completeness, some possible responses I see are:
indicator:
  1. nothing - rely on available markup or replacements from below
  2. strings from somewhere, "(begin table)" "(end table)"
  3. HR at top and bottom.
  4. <TABLE></TABLE> = <p></p> 
  5. capture everything between <TABLE></TABLE> to a buffer, leaving
     behind a [TABLE] link.  User can launch a selected helper app to 
     deal with it, or ask lynx to attempt further rendering.

  I don't really like 5 myself, but the result is compact onscreen, and
  I thought of it, so I put it in, so it can be commented on like the rest.
  If I could think of it, someone else is bound to.

TR specific handling:
  1. nothing - rely on available markup or replacements from below
  2. TR = BR (line break)
  3. TR = HR align="center" width="30%" (small width HR)
  4. string from somewhere (same place as indicator.2?) "(row break)"

  I suppose that the replacement text could be from lynx.cfg, and accept
  valid HTML text (straight macro replacement).  If so, could be a security
  bug?

I encourage blind people or those experienced with screen-readers to 
comment on this one, Thanks In Advance.

special markup to apply:
  1. Absolutely no special handling - ignore table related tags, rely on
     author's other structural markup.

  Lucky break if you can get it.  We might want a key to revert to this 
  (similar to ' toggling smart/stupid SGML comment handling)

  2. Parse table as a list type
   a. DL type - <TABLE></TABLE>=<DL></DL>, TH = DT, TD = DD.  
      The main problem I see here is strictly speaking 
          <dl><dd>bla bla bla<dd>yep indeedy<dd>that's what I said</dl>
      is *not* legal - there should have been pairs of DT's and DD's.

SHML lawyers please comment, Thanks In Advance :)

   b. UL - <TABLE></TABLE>=optional (table begins) (table ends), or HR's
         <TR></TR> = <ul></ul>
         TH = <li> with some special emphasis (maybe a line in lynx.lss)
         TD = <li> without emphasis

   c. OL - row n, col m: -or- cell n.m:
      Sounds pretty good until you consider tables inside tables.  
      A fairly common template I've been seeing has an outer table for
      style (navbar against the left, main text, address section, maybe an
      ad or corporate banner: 3-4 cells) and if the content needs a table
      of one of the other two sorts, then the author will use one.
      So... tables should be given depth names?  "cell A.n.m:  ...
           cell B.1.1:  cell B.1.2:   cell B.2.1:  cell B.2.2:
           ... cell A.n+.m+:  ..."

  3. Some form of screen splitting.
     I could see something like this:
--------------------------- title of page across top of screen ----
        Heading Bla Bla Bla 

        As you can see in our wonderful table
        [TH] [td] [td] [td]
        [th] [td] [td] [td]
        [th] [td] [td] [td]
        
        ... we are the best thing since sliced bread!
        ----------- tables display area
        OUR NEAREST COMPETITOR

        -more- http://www.foojump.com/products/
------------------------------------------------------------------
      ...but then we need to assign a key to switch the "focus"
      between the table-cell and main content.  Essentially we'd be 
      implementing minimal frames.  Sounds like work.
      
I still can't think what could be done to preserve the sense of rowspan
or colspan readily.  However, these have the advantage of being possible at
a macro-replacement level; therefore, they should be something that could
be done without too much deep re-design.  (In other words, in the first
pass like lynx is used to.)

> PW> very recently we've also had a request to mark  <SCRIPT>'s  as such:
> PW> it really would be useful & if it were an option to suppress such things,
> PW> people who have special difficulties could choose not to see them.

I can think of a number of special features I'd like to toggle display or
suppression of, but I'll stick to tables in this thread.

Heather Stern  . | .  starshine.org * Starshine Technical Services
  star at:   --->*<---    lasfs.org * Los Angeles Science Fantasy Society
               ' | `                 

reply via email to

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