Re: table headers - clear description of problem

2008/8/26 Henri Sivonen <>:
> On Aug 26, 2008, at 17:29, Laura Carlson wrote:
>> Source:
> [..]
>> Source:
> It seems that the problem description for headers/id is backwards
> compatibility in case where authors are competent and willing to cater for
> existing UAs not making good use of <th> semantics.
> It appears, though, that if client software is not assumed to be frozen, for
> the next generation of client software the general approach taken by the
> spec (not necessarily exactly as written) is better than the headers/id
> approach, since there less room for author error when tables are edited and
> less participation from authors required, which should improve overall
> accessibility of tables on the Web scale. (It seems to me that
> implementation-wise the right place to put the association algorithm is
> browser engines that report stuff to AT--not AT itself.)

Most of the examples I've seen of complex data tables that require
headers/id associations have not been built by hand. They're usually
built server-side, after analysts select the data they want to report
on, and generating the relationships is easy for the software. When
composite data is included, headers are usually required, as the
composite data has a finite range that might not run for the remaining
column/row. This can sometimes be overcome (if there are no totals or
other aggregate data that usually go in the last columns) by
reordering the columns, but using conceptual headers marked up as tds
with headers/id to create the association allows analysts to order the
columns how they want.



Supplement your vitamins

Received on Tuesday, 26 August 2008 15:53:44 UTC