Re: PFWG report on @headers status

The following is feedback from the Protocols and Formats Working Group
to the HTML 5 WG on the @headers issue for the archive.
This also completes my action item for this issue. [1]

Cheers

Josh

[1] http://www.w3.org/html/wg/tracker/actions/84


** background

- in current draft HTML5
http://www.w3.org/TR/html5/tabular.html#headers
- Wiki anthology of discussion
http://esw.w3.org/topic/HTML/IssueTableHeaders

** function and performance

* ease of authoring

- general agreement that it is desired to improve ease of authoring
from the current state of affairs. Currently only @headers and not @scope
and @scope-related algorithms are implemented widely enough on the
client side.
Due to the poor support for @scope, its use may impact negatively on the
user experience for PWDs, when they interrogate complex data tables.
However, one can make all the necessary cell associations (using
header/id combinations) in a way that does improve the user experience
for PWDs, but with the draw back for authors that this process is a
little more complex.

- general expectation that if client
software implements algorithms that use @scope, cell position, and @headers
well, an improvement in authorability and actual-use rates can be
achieved without sacrificing functionality.

- general sense that the 'smart headers' algorithm is pretty good, and
better than what we had in the HTML5 draft as of 23 October.

* coverage of tables, including large, complex, and irregular tables.

- general agreement that multiple levels of headers are part of the
requirements, are in common use in the wild.  Note that the present
HTML5 draft does not cope with this.

- the accessibility community expects the present capability to handle
complex and irregular tables to be maintained, no loss of functionality or
the accessibility community will resist.

** design notes

* what elements can @headers point at, or what elements can be in scope
of @scope?
- no general agreement on specifics, but general agreement that there
needs to be some widening of the possibilities from the current spec
draft if 'chained header cells' are to be used as the markup for
multiple levels of headers in a table.  To achieve the necessary connection
topology, intermediate chained cells could be <th> or <td>, it can be
made to work either way.  This is an area for further refinement not
resolved at the F2F meetings.

* Cyclic referencing

There has bee some concern voiced about the potential for cyclic
references if chained headers were allowed in the specification. This
seems to some degree to be unfounded. The relationship between a header
and any corresponding chained/nested/ conceptual header that follows it
is uni-directional and not bi-directional. This also follows if the id
of a <td> cell is to be referenced from a chained header.

Received on Monday, 24 November 2008 14:01:37 UTC