W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2003

RE: [#293] Summary for tables

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Wed, 11 Jun 2003 07:59:41 -0500
Message-ID: <B3DC65CD2AA7EF449E554548C6FE111113565D@MAIL01.austin.utexas.edu>
To: <jasonw@ariel.ucs.unimelb.edu.au>, "Al Gilman" <asgilman@iamdigex.net>
Cc: "WAI GL (E-mail)" <w3c-wai-gl@w3.org>

Jason's proposal to use class="layout" to distinguish layout tables is
intriguing.  What implications does this have for user agents?

John Slatin, Ph.D.
Director, Institute for Technology & Learning
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.ital.utexas.edu

-----Original Message-----
From: Jason White [mailto:jasonw@ariel.ucs.unimelb.edu.au] 
Sent: Tuesday, June 10, 2003 8:19 pm
To: Al Gilman
Cc: WAI GL (E-mail)
Subject: Re: [#293] Summary for tables

Al Gilman writes:
 > This comment from Phill Jenkins:
 > The summary attribute was not discussed in the June 9th proposal.  It
is  > the one attribute unique to layout and data tables that could be
used to  > help confirm that, in fact the should's and must's have been
followed and  > in fact this table is or is not a layout table.  The
convention I have been  > proposing is to use the keyword "layout" in
the summary attribute text.

Problems with this proposal:

1. It is language-specific (ie., English only).

2. The contents of SUMMARY are meant to be presented to the user, not
   interpreted by the user agent and we shouldn't violate this

3. There is a feature of HTML/XHTML designed exactly for the intended
   purpose, namely the CLASS attribute.

Proposal: CLASS="layout"

Some have argued in the past that we shouldn't attempt to establish
conventions for the use of the CLASS attribute, as its semantics are
intentionally left open by the HTML and XHTML specifications. A parallel
case can be mounted, however, with respect to SUMMARY - the original
proposal would partition the set of SUMMARY values into two subsets
according to whether or not they contained the word "layout", and would
then attach specific semantics and behaviours to summaries in which the
word appeared. If we are going to set expectations for developers
regarding the semantics of attributes of the TABLE element I would
prefer to constrain CLASS than to constrain SUMMARY.
Received on Wednesday, 11 June 2003 08:59:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:44 UTC