complex tables: heading cells and summary cells

Hello all,

I think we're making decent progress on the issues surrounding the  
need to include @headers for compatibility reasons (also @abbr for  
accessibility reasons). With that in mind, I have turned to focus on  
the issue of complex tables and associating data cells with heading  
cells and summary cells.

To examine this issue, I created an example of a (semi-)complex  
table. This is a more abstract approach then some have advocated, but  
I think it's useful to prove a complimentary way to think about  
tables and also it can provide a way to discuss the issues  
independent of any concrete table. I would like to add this table to  
the wiki, but I haven't figured out how to add direct HTML syntax.

On terminology, I'm going to use the term heading instead of header  
because I think it better expresses the meaning of the cell: that is  
that a TH cell is a heading expressing heading or title metadata  
about a data cell. The term "header" can often be confused with a  
runner like a table header that I want to distinguish here. In other  
words a runner (header) may contain relevant metadata about the data:  
including the heading. However, a footer may also contain relevant  
metadata about the data cell as a trailing runner.

A few things to note about this table:

  1) though it is rather complex (and could be made more so simply by  
repeating the pattern), it includes no @scope, @axis, or @headers  
attributes.
  2) despite its complexity, I believe an algorithm could easily  
associate the data cells with the heading cells (and vice versa)  
without the need for either @scope or @headers
  3) @scope would be needed ONLY if colgroup or rowgroup headers were  
used that did not span the column group (colgroup) or row group  
(tbody). By not spanning the column group or the row group, a column  
group or row group headings would be difficult to convey visually.
  4) @headers would be needed only if tables used headings in cells  
in a different row or column than the data cells or in a place non- 
contiguous with the data cells (other than the global headings). This  
seems to me to be a difficult extension of tables beyond their  
purpose and difficult to maintain a visual presentation of them,  
which is mostly their purpose).
  5) @axis would be needed to express other axes beyond the 2  
dimension of a table (this could be visually presented as a  
background or foreground color, for example, through a CSS attribute  
selector). This seems to me to be a manageable and worthwhile  
extension of table capabilities beyond the complexity in the example;

I haven't tried to apply this to the HTML 4.01 table examples, or to  
Ben's interesting tables[1], but I'd be interested in what others  
think. What I find interesting in this example is that:

  1) there is other information that should be associated with a data  
cell (such as its column or row summary and both local and global  
headings and summaries). For example aural browser users might want  
to quickly access a table cells column or row summary.
  2) there are global headings and summaries relevant to all cells
  3) perhaps neither @scope nor @headers is needed to express complex  
tables (though for backwards compatibility it must remain). I'd like  
to hear what reasonable changes to this table might make it need  
@headers or @scope to express the complexity.
  4) We may need a way to express a summary cell (this could be  
implied by a TH cell at the right or bottom of a tbody).
  5) we may need a way to express "left" and "right" or "East" and  
"West" global heading and summaries. In other words we have no TSTART  
or TEND elements that could contain global attributes (such elements  
might get printed repeatedly on each page of a very wide table, for  
example).
  6) perhaps all cells in a TR in a THEAD or TFOOT should be  
considered global table headings and summaries respectively (in other  
words, a data/heading associating algorithm should also match data  
cells to the global headings and summaries)
  7) with @axis we would also want to make headings along any axis  
available in aural presentations (perhaps through a DOM method like  
headingsOnAxis(in DOMString, axis)).
  8) we may want to provide access to local and global corner cells  
(those buried both vertically and horizontally by header cells) if  
they have content.. This too could be exposed through a DOM method on  
HTMLDataCell interface like cornerCells() that returns an  
HTMLCollection containing the corner cells.

Any thoughts?

Take care,
Rob

[1]: <http://sitesurgeon.co.uk/tables/readme.html>