Table header cell scope

Problem statement / use cases

• The scope attribute for associating table header cells with table data cells is ambiguous due to its enumerated values
• The scope attribute’s enumerated values can allow users to create associations that are not visually apparent nor conforming to typical table authoring

The scope attribute currently (from HTML4 and in the current HTML5 draft) takes one of four values (from HTML4.01):

“This attribute specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of the headers attribute, particularly for simple tables. When specified, this attribute must have one of the following values:

• row: The current cell provides header information for the rest of the row that contains it (see also the section on table directionality).
• col: The current cell provides header information for the rest of the column that contains it.
• rowgroup: The header cell provides header information for the rest of the row group that contains it.
• colgroup: The header cell provides header information for the rest of the column group that contains it.”

There are several subtle problems with these definitions. First, header cells should apply in either a vertical or horizontal direction when scoped or in both directions (vertical and horizontal) when not scoped. However, the distance (i.e., the number of data cells) to which the header cell should apply is a separate issue. As an example consider only the horizontal application of a header cell. If the header cell applies horizontally to the subsequent data cells in the row the second question is how far should the header cell apply. Should it apply to the rest of the current colgroup or to all the remaining data cells in the row until the end of the table. So by selecting colgroup, the author intends to apply the header cell to the row, but only for the remainder of the colgroup. Or the author intends to apply the header cell to all of the data cells in a colgroup, but that would never be apparent to a visual consumer of the table (nor does it correspond to actual table usage and design).

So for the former case, where colgroup applies to the rest of the data cells in the row for the current colgroup, this is confusing for the authors (using “colgroup” to apply to a row). Of course the same thing applies to col and rowgroup.

Another problem with these scope values is that they try to accomplish associations that cannot be made apparent to the visual consumer of the table. For the visual consumer of a table header cells only apply in one of several ways.

• Vertically
  1. a column header cell applied vertically to the remaining data cells in the table (the header may also span two or more columns)
  2. a column header cell applied vertically to the remaining data cells up until the next header cell (the header may also span two or more columns)
  3. a column header cell applied vertically to other data cells up until another logical break (which might or might not be based on rowgroups— tbody, thead, and tfoot elements; in some table designs the author cannot provide tbody rowgroups to reflect the necessary data structure of the table)
• Horizontally
  1. a row header cell applied horizontally to the remaining data cells in the table (the header may also span two or more rows)
  2. a row header cell applied horizontally to the remaining data cells up until the next header cell (the header may also span two or more rows)
  3. a row header cell applied horizontally to other data cells up until another logical break (which might or might not be based on column groups — colgroup elements; in some table designs the author cannot provide colgroup column groups to reflect the necessary data structure of the table)
• Corner Header: a header cell in a corner of a table where no data cells appear either vertically beneath the header cell nor horizontally after the header cell. In such cases the author intends the corner header cell to either:
  • augment the meaning of the column header cells appearing horizontally after the header cell
  • augment the meaning of the row header cells appearing vertically below the header cell
  • augment the meaning of both the header cells appearing vertically below and the header cells appearing horizontally after the corner header cell
• An isolated header cell with data cells horizontally after and vertically below
  • such a header cell is rare in normal tables

Note this last concept of a corner header cell implies that the header cell only applies to data cells indirectly through its application to other header cells.

In summary the four values for the scope attribute create ambiguity for authors and also permit the association of header and data cells not corresponding to visual table consumption.

Proposed solutions

• change the values to scope to “vertical”, “horizontal” (or “v” and “h”)
• make a separate attribute for corner header cells called “applytoheaders” with values to indicate ”both”, “none”, “horizontal”, or “vertical”
• require the applytoheaders attribute for corner header cells (machine checkable)
• require that the headers attribute always reference an IDREF for a cell either vertically above or horizontally before the cell (header or data) on which the attribute is used
  • also taking into account span values on both the referencing cell and the referenced cell where there must be some horizontal or vertical overlap
  • perhaps introduce a pedagogical concept of the horizontal and vertical bar test for these idrefs where the rectangular cell creates a horizontal and vertical bar that must intersect any header cells referenced by the headers=IDREF attribute
  • this is machine checkable

Examples

Shows a corner header cell

<table>
<tr>
  <th>corner</th>
  <th>A</th>
  <th>B</th>
  <th>C</th>
  <th>D</th>
</tr>
<tr>
  <th>1</th>
  <td>1A</td>
  <td>1B</td>
  <td>1C</td>
  <td>1D</td>
</tr>
<tr>
  <th>2</th>
  <td>2A</td>
  <td>2B</td>
  <td>2C</td>
  <td>2D</td>
</tr>
<tr>
  <th>3</th>
  <td>3A</td>
  <td>3B</td>
  <td>3C</td>
  <td>3D</td>
</tr>
<tr>
  <th>4</th>
  <td>4A</td>
  <td>4B</td>
  <td>4C</td>
  <td>4D</td>
</tr>
<tr>
  <th>5</th>
  <td>5A</td>
  <td>5B</td>
  <td>5C</td>
  <td>5D</td>
</tr>
</table>

Discussion and evaluation

Email

WG members should post feedback and other discussion to the WG’s list serve (the URI for the links below provides date information). Search on this email subject.

See also