Re: No SUMMARY attribute in tables for layout

Any kind of summeary forces me to read it since untill I have read
otherwise, I am under the impression that this is a data table.  summary is
not to describe the lay out, it is to describe the datta in a table such
that it can be communicated in an over view fashion for those who need and
or who can take advantage of it.  When summary was introduced, it was
introduced and discussed as a form of encapsulated data presentation.  A
summary if you will is kind of a long desk for data tables but it is
meaningless in any other case such as:
summary: this table holds the navigation menu and is grey and white".
I see dozens of these and it slows down my reading because it is irrelivant
but I am caused to read them so as not to possibly miss a data table.

There is not much difference betweena lay out and a structural table except
that the latter should hold data otherwise, there is really nothing to
structure.

----- Original Message -----
From: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
To: <w3c-wai-ig@w3.org>
Sent: Wednesday, January 22, 2003 3:34 AM
Subject: Re: No SUMMARY attribute in tables for layout



On Wed, 22 Jan 2003, Jesper Tverskov wrote:

> If we all agree that the summary attribute should only be used for data
> tables,

We don't. This has been discussed a few times on different fora,
and it has been pointed out that it might help to know that a table
is for layout only and, perhaps more importantly, that the line between
structural and layout tables is not clear cut.

A well-written layout table linearizes well. For such a table, a user
agent that presents the content non-visually should simply present the
contents of the cells in order, rowwise, as if the table structure were
not present at all. But there are other layout tables as well, and for
some of them, access to the content on a cell by cell basis might be
necessary. Or consider the rather common design that, at the simplest,
consists of two cells, one on the left containing a navigation menu,
perhaps a big one, and another on the right with the content proper. It
linerizes in a sense, but surely you would like to be able to access the
cell contents individually, so that you can easily select the content
cell.

And this takes me to the other issue. Such a table is a trivial, but
relevant, example of something that exists for layout in a sense but also
exhibits real structure. Using
summary="This two-cell table contains a navigation menu in the first cell,
content proper in the other."
would seem pretty natural and potentially useful.

Such a table differs from, say, a single cell table used just to draw some
borders around something, or a one-row table used to divide text into
columns so that the text of a cell continues immediately in the next cell,
so that the division is based purely on visual balancing, as in a
newspaper article.

> and considering that 99,99% of tables used today is used for
> layout,

The actual figures are irrelevant, but I think you're exaggerating
somewhat. Pure data tables are not rarities, and semi-structural tables
like the one I described above are fairly common.

> the WAICAG should tell us not to use the summary attribute in
> tables for layout and tools for validation should accept missing summary
> attributes in tables for layout.

It's hard to deny the need for a clear statement on this. But its actual
content is more difficult. Somewhat analogously with alt attributes, we
might say that lack of summary attribute indicates lack of information
about the nature and structure of a table (so it could be layout or
structural), and summary="" indicates layout table. This would be a bit
illogical though, if summary is understood as describing the purpose and
content of a table as well, as some specifications suggest. But if such a
convention is made, I think summary="" should mean 'purely layout', in the
sense that non-graphic browsers would be recommended to ignore the table
structure complete, treating each <td> effectively as <div>.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Wednesday, 22 January 2003 08:18:41 UTC