Re: lynx-dev Table support?

[Heather Stern]

I ate the fortune cookie first, then read what Larry W. Virden wrote:
> Re: table labelling
> 
> Are you envisioning literally using letters and numbers?  Or would the
> labels be row and column headers, if provided?

A real pain is distinguishing between tables for style (usually marked as
border=0) and tables for content, compounded by tables inside tables.  I
*know* that HTML code has support for specially marking sections, but 
almost no site I know uses those... they just put tables inside tables, 
and let the double border or the idea that it's "floating in space" as a
sidebar give the delineation.

To my mind, this argues for treating borderless tables differently than 
bordered ones.  By stating border=0. the author is advising us that the
table is stylistic, for layout, and we can use it as a cue to have <td>'s
act like fake <p> containers, and do something really minor for the row
boundary.  It has to be minor, because we're being asked to minimize the
impact of the table edges.  A possible example:
-= table: table_title_here
  a paragraph which happens to be cell 1 blah bla bla ginger blah blah.

  a paragraph which happens to be cell 2 and spans two columns doesn't
  really bother to mention it. 
  --
  a paragraph which happens to be cell 1 in row 2 yada yada blurb.

  -= table: inner_table_title_here
    blurby blurby sidebar
    --
    blurby 2
    -- 
    blurby 3
  -= end of table

  et cetera ad yawn
-= end of table

I consider this is a tiny amount of interference with just reading the table
content.  Listing cell coordinates or some other thing is very confusing to
me.  I don't think cell coordinates would improve the viewability with a
screen reader as much as the above might.

If it was trying to be a calendar, it might look like this:
For purpose of example, I compressed out the line breaks.  In practice 
we'd have to leave em in, I think, because we parse straight through, 
and we cannot know ahead of time that I'm using itty bitty paragraphs like
these, I could have babbled a while.
-= table: 1st week of May
  monday
  tuesday
  wednesday 
  thursday
  friday
  --
  BASFA pizza -skip this time
  nav Byron to potluck
  SVLUG - scalability.
  board meeting
  adjust websites w/ news of the week
  --
  .
  .
  afterdinner.  Possibly savitsky's if time left
  check friend's cats
  .
-= end of table
  
I had to think of something to depict empty cells so they "line up". I don't
think it's as clear what's going on if I use spaces.

Something like the cute edges you folks have been depicting look better if
they are the same kinds of edges.  Nesting levels can then be distinguished
by the type of edge.  eg:
   +--table: table title here -----------------------------+
   |  bla bla bla the      |  .:table: hot or not?:::::::. |
   |  paragraph continues  |  : wired     :        tired : |
   |  downward for a       |  :::::::::::::::::::::::::::: |
   |  while....            |  : foo       :          bar : |
   |                       |  '::::::::::::::::::::::::::' |
   +-----------------------+-------------------------------+
   |  etcetera             |  and so forth.                |
   +-----------------------+-------------------------------+

Mind you too many levels of nesting annoy me in the graphical browser - 
it usually is combined with tiny-print-osis.  I wouldn't mind an option to
always treat the tables as borderless, if I like the borderless layout 
better.

Still dunno what to think about rowspan though.  Real tabular content 
uses rowspan as content that is the same for multiple columns, so it
would be possible to depict merely by repeating the spanned cell when 
its next-row-cell comes back around. (oh no, more buffers to protect 
from overflow.) But when it's done left to right (er, at least in 
english, a left to right language) it might be better depicted as a 
deepening list.  (It might have been better depicted as that anyway, 
but the author chose a table. oh well.)

Are we going to make any effort to distinguish TH cells from TD cells?

I also wonder how the selected layout will affect people who've tried to
support both tabled and non tabled browsers by having extra cells to 
suggest line breaks in the right places.

All in all, whatever is selected, I hope that it would read at least as 
well as if I were to try and tell a friend over the phone about how a 
table is laid out on a graphical web page.

  . | .   Heather Stern                  |         address@hidden
--->*<--- Starshine Technical Services - * - address@hidden
  ' | `   Sysadmin Support and Training  |        (800) 938-4078

Not to laugh, not to lament, not to curse, but to understand. -- Spinoza