RE: linearized tables

At 09:01 AM 3/14/00 -0600, thatch@us.ibm.com wrote:
>The Form example is no less a table than
>the TV listings. The Form example is properly marked up if appropriate
>table markup is used. Of course the form can also be marked up with the
>LABEL element.
>
>My bottom line is that when row-column position carries meaning, then
>linearization is not relevant.

Jim,

I've been trying to figure out how to answer this formal 
characterization.  The problem I have with it is the practical consequence.

Lets say I'm dealing with a designer constructing this form we've been 
talking about, with name, address and phone across the top and three fields 
across the bottom (I'll the the fields FIELD instead of writing out <INPUT 
type= etc. etc. etc. etc.>

If the designer construct this with a 2 row table, a typical user agent 
will read it

name, address, phone, FIELD, FIELD, FIELD Clearly suboptimal.

But if the designer makes a trivial change... implementing it as a one-row 
table, with name <BR> field in the first cell, address <BR> field in the 
second, and phone <BR> field in the third, then it gets read

name, FIELD, address, FIELD, phone FIELD.

In other wise, an easily understood reading order.

If I follow your argument that linearization is not relevant, it means I 
don't tell the designer to use the second, more accessible design.  I just 
can't accept that.

But I've got to admit that, yes, formally speaking this is a table in the 
data sense (something that greg said also) so technically speaking  I'm 
stuck with this consequence.  So how to get out of this.  I suggest a new 
requirement:

Ban the use of "degenerate" data tables, i.e. tables that only have one 
data row (in addition to the headers).  Note that this does not apply to 
tables with a variable number of data rows... e.g. results of search 
operations.

Degenerate data tables may be replaced with presentations that preserve the 
visual appearance, e.g.

  - a one row layout table with <BR> separating the (former) heading and 
data in each layout cell
  - CSS positioning of the elements (only recommended when CSS layout is 
universally bug free)

They may also be replaced by other layouts, e.g.
name: FIELD  <BR>
address: FIELD  <BR>
phone : FIELD  <BR>s

or a description list,

The choice is up to the author.

That way we recognize the formal characterization of the 2-row design as a 
two row table, but avoid the undsirable practical consequence.

Does that sound OK?  If not, is there some other way to avoid the 
consequence?  Are we  stuck with the consequence, driven to it by this 
logical analysis?

Len
-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University
423 Ritter Annex, Philadelphia, PA 19122

kasday@acm.org
http://astro.temple.edu/~kasday

(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Wednesday, 15 March 2000 22:01:08 UTC