W3C home > Mailing lists > Public > public-html@w3.org > March 2010

ISSUE-92 Change Proposal

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 31 Mar 2010 06:59:13 -0600
Message-ID: <k2g643cc0271003310559ldacbca56y3d851588aacd79e4@mail.gmail.com>
To: HTMLWG WG <public-html@w3.org>

    Summary: Replace too-simple and somewhat odd example table and
verbose text unrelated to the table element, with one example table,
derived from real world data that best demonstrates the table element.
Refocus the text specifically on the table element.


In the bug[1] related to this issue, the HTML5 Editor's rationale for
not make this change was:

    Rationale: Given how bad the current situation is regarding
authors providing
    explanatory text for tables, I think we should given them as much
    as possible, in as many places as possible. We do AT users a
disservice if we
    pretend that their needs aren't important enough to include advice on how to
    best serve them in the spec.

The current table element section provides one very small and
inadequate table example, with a great deal of prose basically telling
people what to put in text surrounding the table. None of this prose
is related to the purpose and interoperable use of the table or its
child elements, and seemingly added to the section only as a way of
justifying removing the summary attribute. I hate to use cliches, but
this seems like a true case of the tail wagging the dog.

Throwing lots of irrelevant text at authors does not make the table
element any clearer, or ensure they use the element in the proper way.
What's needed is a good, succinct example, with a clear explanation of
the element, and the table's only unique attribute, summary.

What people incorporate into the text surrounding an HTML table _is
not the business of the W3C HTML Working Group_. Such
over-specification only adds to the noise, and if you throw enough
noise at people, all they'll do is tune out the important bits.

The space would be better used by providing a table listing that uses
all of the table child elements, demonstrating how the elements work
together, and then providing a screenshot of the table. By creating a
listing, people can see how the table is put together; the figure
demonstrates the visual rendering of the table.

In addition, we shouldn't belabor what is already a well known
restriction on tables: don't use them for layout. Say it once, say it
succinctly, and then move on. Don't continue to 'pick' at the spec


Replace the existing table element description section with the
following (replace the URL for the img element in the figure with one
local to the W3C, image can be copied, add appropriate cross-reference

The table element represents data with more than one dimension,
organized into non-empty columns and rows. It is the primary component
of the table model.

Tables are used for data display, only, and should not be used for
layout purposes. In particular, users of accessibility tools like
screen readers are likely to find it difficult to navigate pages with
tables used for layout.

The only unique attribute for the table element is the summary
attribute. This attribute is optional, and should only be used with
complex tables, in order to provide a visual description of the
structure of the table—making the table easier to navigate when
rendered non-visually. The summary may also include a brief
description of the purpose of the table, if such purpose is visually
apparent when viewing the entire table, but may not be apparent
traversing the table, cell by cell. An example of a complex table,
contained within a web page and with CSS styling, is shown in Listing
Table-1. Figure Table-1 is a visual rendering of the table.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<title>Example Table</title>
  border: 1px solid #ccc;
  border-collapse: collapse;
  margin: 0 20px;

td, th
  border: 1px solid #ccc;
  padding: 10px;

  background-color: #ffc;

  font-size: smaller;
<table summary="First row is column headers separated into year and
degree programs
                (bachelor, master, graduate). Each degree program is
further split into
                biology and technology fields on second line. Each
topic field is separated into
                male and female graduates on third row. Years are
listed in first column.">

      <p>Degrees in the biological and biomedical sciences compared
with degrees
         in technology conferred by degree-granting institutions, by level of
         degree and sex of student: Selected years, 2002-2007.


   <colgroup span="1"></colgroup>
      <col class="male" />
      <col class="female" />
      <col class="male" />

      <col class="female" />
      <col class="male" />
      <col class="female" />
      <col class="male" />
      <col class="female" />

      <col class="male" />
      <col class="female" />
      <col class="male" />
      <col class="female" />

         <th rowspan="3">Year</th><th colspan="4">Bachelor's Degrees</th>
         <th colspan="4">Master's Degrees</th>
         <th colspan="4">Doctor's Degrees</th>

         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th></tr>








         <td colspan="13">Data from Institution of Education Sciences
National Center
                for Education Statistics, derived from two tables:
                Table  298. Degrees in the biological and biomedical
sciences conferred by degree-granting
                institutions, by level of degree and sex of students;
selected years, 1951-52 through 2006-07
                </a> and <a
                Table 302. Degrees in compueter and information
sciences conferred by degree-granting
                 institutions, by level of degree and sex of student:
1970–71 through

(image can be found at http://burningbird.net/images/table.jpg)

Screenshot of Example complex table contained in Listing Table-1

Other changes:

For each of the table element children in the listing—tr, th, col,
colgroup, caption, tbody, thead, tfoot—reference the existing example
in Listing Table-1, and remove any other example table. One example
should be sufficient to demonstrate all of the table model elements.

Though this is more related to Issue 32, it's still relevant: remove
the warning about the summary attribute, and remove the attribute from
the "obsolete but conforming" section. We've beat this horse so much
that it's practically glue. Time to open the gates and let it loose.
Time to move on to other things.


Positive Effects

Replaces an unbelievable table example, with one that is believable,
using real data. In the spec, we should avoid contrived and made up
examples, as much as possible, as they can undermine the credibility
of the section, and distract from element(s) being demonstrated.

The change also clarifies the section and puts the focus back on the
table element, rather than anything but. The example also demonstrates
how to use all of the table elements, as well as making a correct use
of the summary attribute. Linking all of the table child elements back
to the table element section and the listing allows people to see how
these elements are used, especially in context.

Negative Effects

Will take some of the editor's time to make this change. The use of
labels such as Listing Table-1 and Figure Table-1 may not fit it
within the writing style of the rest of the specification (adjust as
necessary). The listing is also a little large, though as a
demonstration of a family of elements, not overly so.


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8449


Shelley Powers
Received on Wednesday, 31 March 2010 12:59:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC