Re: Table Questions

[firehose warning (picky detail, thorny theory)  - Al]

At 01:05 PM 2001-05-11 -0400, you wrote:
>Everyone's comments have been incredibly helpful; of course, I always seem
>to have more questions!
>
>In regards to the data vs. layout table issue, I would like to present the
>following example:
>
><<http://www.geocities.com/lizdesign/tables.html>http://www.geocities.com/
lizdesign/tables.html>
>
>Supposing this is a data table, the top-level "header" is "Property
>Description," with "Name," "address," and the like a "second level" of
>headers (labeled as TDs because: "TH is for headers, TD for data, but for
>cells acting as both use TD"
><<http://www.w3.org/TR/html4/struct/tables.html#h-11.2.6>http://www.w3.org
/TR/html4/struct/tables.html#h-11.2.6>).  Of course, the
>spec doesn't show an example of such a construct... should you use "id" and
>"headers" with TDs?  ("headers" are not included in example because I wasn't
>sure.)

AG::

You have (it's subtle here) misinterpreted the "use TD when both" rule as it
affects this table.  The marking "Address:" is clearly a header for the
cell to
its right, and only a header.  It introduces no data for the purposes of the
"if both" suggestion.  So that cell (and all cells in columns one and three
below the initial spanning table header) should be coded as TH to use the
markup in a manner consistent with this comment in the DTD.  Not that it
matters.  The distinction between TH and TD is not generally used right, so
why
should you?

Yes, you may use ID on a TD and point to a TD with HEADERS where you have
followed the comment about "use TD when both."  In particular, if you use
HEADERS in this way you have insurance against errors in determining what is a
TH and what is a TD.

Your example can be considered as a layout table used to wrap a two-column
data
table into a folded layout of two (newspaper-like) layout columns.  There is a
"data table" relationship in that the Column 1 entries are headers for the
Column 2 entries and the Column 3 entries are headers for the Column 4
entries.  But, as Steven McCaffrey confirmed, it passes the "makes sense when
linearized" test.  

[By the way, we just disproved Jim Thatcher's supposition that five experts
would agree.  This test table is one that would divide the gut reactions.  I
still suspect that for cases _where it matters more_ you could expect that
five
experts would agree, but twenty-five might contain a dissenting vote, an
alternate interpretation.]

The semantic definition I would suggest you use for "data table" as used in
the
508 Regulations would be that it is a "data table" if there is a _recurring
pattern of relationships_ which appears repeately in _similar groups of
cells_,
and it is important to understand that pattern of relationships _in
addition to
the cell contents_ to understand the information provided by the cell
contents.

In the present case, there is a recurring pattern of relationship, but it is
not necessary to understand the cell contents.  The cell contents themselves
evoke the relationship adequately without recourse to the structured context.

In this case, there is a recurring "field name, value of this field for this
residence" pattern in the table, but the way the field names are stated one to
one with the data for the fields makes the relationship obvious from the cell
contents alone,  It is not necessary to recall a pattern from the context to
interpret the cell contents.

[It is not just a list.  It is a labeled list.  The pattern of (field label,
field value) repeated forms a relation, that is, a logical table.  But it is a
simple one.]

All that is more theory than you wanted, but that is the sort of test that the
508 rule equates to.

The simple rule, "Use the other markup for any table which fails the 'makes
senses as linearized' test" is practical and may prove to be sufficient in
most
cases.

The highest and best markup for your example is to make the cells in columns 1
and 3 be TH cells, the cells in columns 2 and 4 be TD cells, and the cells in
columns 2 and 4 have HEADERS attributes which point to the header cell
immediately to their left.   The way you have laid it out, there is a
two-column data table which has been further folded into two layout-columns of
two table-columns each.  In this layout the SCOPE attribute would be ambiguous
and you should use HEADERS in preference to SCOPE in this layout.

[And Jim reports the screen readers don't know from SCOPE anyway.]

For this particular table, the distinction between data and layout structures
is largely academic, because the table works as linearized.  The regular
structure is present but not critical to be remembered.

The data-to-header relationships that I above suggested you mark are
equivalent
to the results of the "guessing" algorithm suggested in the HTML 4
specification, but it does not hurt to be explicit.  The explicit markup is
not
excessive or in any way negative in this case, because the indicated HEADERS
relationships are genuine, even if they point to something that came just
before in the linearized reading order.

>I feel like I'm using a table for layout... but if I think about the data
>logically, it seems like there are logical headers, etc.

AG::  In the table you built there are both logical and layout structures
present.  You are using table layout for logical connections, and for
effective
use of the space available, both.

>
>And on the page before my example one, there are search results that I don't
>feel use the table simply for layout.

AG:: How do we get to this "page before?"

Al

>
>Thanks again,
>Liz
>

Received on Friday, 11 May 2001 18:43:30 UTC