RE: HTML5: First Public Working Draft Released

On Mon, 2008-02-04 at 08:45 -0600, Robison, Cole [EISU] wrote:

> I noticed [the missing @headers attribute], too. The scope attribute
> is still there. Are there cases it can't cover, for which headers
> and/or axis would still be needed?

For some reason it's not very easy to find tables that can't be marked
up sufficiently with @scope attributes. I've seen theoretical examples
("Imagine a table with different headers at each end of the rows"), and
scans of tables from the 1800's with headers and data mixed together in
a melange that would make Edward Tufte cry, but those could easily by
recast as multiple tables with @scope attributes. HTML is about marking
up the content, not about marking up the presentation.

In the absence of decent examples, I tried coming up with one on my own.
My example is at http://www.outstandingelephant.com/unscopabletable. It
has header cells in every other row, and I think it presents the data
better than many separate smaller tables would be able to.

Also consider these points:

1) The HTML5 @scope algorithms require knowing the x- and y-coordinates
of each data cell. Because cells can span multiple columns and rows, the
coordinates cannot be reliably calculated without processing every
previous cell in the table, which can be a time-intensive operation with
large tables. The @headers attribute requires a lot less processing.

2) It's never been clear how @scope is supposed to work with headers
that span multiple columns. If a header has @scope="col", and the cell
spans across an entire column group, does the header label every cell in
the group, or just those in the first column?

3) @scope limits tables to four dimensions (colgroup, col, rowgroup and
row). Especially with the @axis attribute gone as well, this severely
limits the amount of data any one table can present (though maybe that's
a _good_ thing).

One good thing I can say about HTML5 is that there is an actual,
explicit algorithm for determining which header goes with which cell
based on the @scope attribute, and, even better, _in the absence of any
scope attributes at all_. This means that AT vendors have a standard way
to parse the vast majority of tables that have no accessibility
information aside from the presence of header cells (which let's be
honest is the vast majority of data table on the Web).

Because there are tables that don't fit into that majority, however (as
linked above, for example--and small minorities is really why at least
I'm here), I would like to see the @headers attribute returned to the
spec. I propose that neither it, nor @scope, should be required, as the
automatic scoping algorithm covers most situations. But it should be
there for when we need it.

And if the @headers attribute is lost to the ashes of HTML4? Then I say
that , where we have to, we continue using it anyway. AT and even
browser vendors have a long history of embracing the actual practices of
the Web when the standards do not. Consider the innerHTML DOM property,
for example, which is unsanctioned by the W3C but can reliably be used
across scriptable browsers.

If we use the @headers attributes, then the attributes will be used.

Chris

Received on Monday, 4 February 2008 19:09:36 UTC