Re: @headers on th too or just td?

Steven Faulkner 2008-06-27 12.00:

> I discussed the issue of @headers on th elements with Gez lemon:
>  
> he came up with some info on the topic:
>  
> http://www.w3.org/TR/html401/struct/tables.html#h-11.2.6
>  
> In the DTD fragment, they have the following comment:
>  
> <!-- TH is for headers, TD for data, but for cells acting as both use TD -->
>  
> And then down in the associating header information with data cells:
> http://www.w3.org/TR/html401/struct/tables.html#h-11.4.1
>  
> They have:
> "Note that it's not always possible to make a clean division of cells
> into headers or data. You should use the TD element for such cells
> together with the id or scope attributes as appropriate."
>  
> Considering that, it's a bit strange that they allow the headers
> attribute on th elements. Having a header implies that the cell
> contains data, in which case it should be marked up with td. That's
> probably why HTML5 have removed it from there, as it wouldn't make
> sense.

Those bits of HTML 4 have been aired before in our debates, but 
not with that kind of twist. So let me comment your conclusion 
that HTML 4 is in disagreement with itself here ...

We can look at the H43 table Dan mentioned. According to your 
reading, then, the second row of headers should really be TD cells 
... However, HTML 4 doesn't say this. It only say that you should 
use TD if you cannot make a clean division between data an heading 
content. That cleanness isn't blurred by the fact that even a 
header cell can have its own header, though ...

Like I have said before, HTML 4 seems occupied by *limiting* the 
association - not associating too much. *That* is the reason why 
it says you should use a TD if a header genuinely plays the role 
both of data and of header. (For instance, a cell might be a 
header for only a select group of cells.) And another reason is 
the way the HTML 4 algorithm for searching up header cells works: 
the search will end if the cell after a header cell is a TD cell. 
Thus placing a lone header cell in the middle of a table could 
cause the cell beneath that cell to only see that single cell as 
its header cell.

Looking at h43 again, if had been important to say that the 2nd 
row *only* had headers for - let's say - a 3rd row, but not for a 
4th row, then you could use TD cells in the 2nd row and use 
@headers in the 3rd row too tell that the corresponding cell in 
the 2nd row was its header. The cells in a 4th row would then not 
be "disturbed" by any "local" header cells in the second row, but 
would only see the cells in the 1st row as header cells.

Another consequence of HTML 4 is that a TD can act as header cell, 
if you list it in the @headers attribute of another cell. Has this 
beecome permitted in HTML 5?

HTML 4 allows you to place a row of headers in a middle row of a 
table. Unless you include @headers in the TH cells of that row, 
then the cells beneath that row, will only see the cells in that 
middle row as its column headers. And that might be exactly what 
you want! If you also want those cells to also see the top row of 
headers as header cells, then these/those cells must be mentioned 
in a @heades attribute of that middle row of header cells.

Such fine tuning is not - I think - possible with current HTML 5 
approach, were the goals seems to be to associate as much as 
possible. (I'd like to be corrected.)

Apart from the lack of fine-tuning in the HTML 5 algorithm, I 
don't know if it makes sense for screen readers to always read all 
the related header cells that could be found via a less discerning 
algorithm than the HTML 4 algorithm. Via the HTML 4 algorithm, it 
is possible to "compose" what the useer is suppose to hear. With 
HTML 5, the assumtion is that the reader want to hear all header 
cells, always.

The debate is assuming, it seems, that the association of header 
to datacells is a such a big problem. But it is not. Everything in 
a table is supposed to be related - one only need to search up the 
headers ... That is why you placed it in the table, because it is 
related. The trouble is finetuning how things are related. Even if 
the header in the middle row are lacking the @headers attribute, 
so that the the logical top cells are not included, I would still 
suppose that a screen reader user who knows that the cell in the 
first row is related as well, can ask the software to hear it.

The HTML 4 algorithm, with the @headers in the TH cells, allows 
you to set-up "contextual" header associations. (When a @headers 
include a list of idrefs, then the user agent might not know which 
of these idrefs are the most important ones, for instance. The 
orde of appearacne might also be accidental. (Doen't screen 
readers read the header cells in the order they are listed in the 
   @headers attribute?) That's the drawback of using the 
"super-compatible-stupid-method" of using a @headers attribut on 
*every* cell, were you list *all* related headers - then the 
@headers attribute often ends up containing no other info than 
what the screen reader software could have dedcuced by itself. ANd 
how can the screen reader use tell, by looking at the IDREFS in 
the @headers attribute, which of the headers is the closest or 
most distant one? That should be very relevant info.)
-- 
leif halvard silli

Received on Friday, 27 June 2008 14:34:08 UTC