Re: @headers on th too or just td?

just to make it clear, i offered no opinion of my own on the subject, i was
just passing on some insight/info from Gez.

everything below "I discussed the issue of @headers on th elements with Gez
lemon:
 he came up with some info on the topic:"


is what Gez related to me.

regards
stevef
2008/6/27 Leif Halvard Silli <lhs@malform.no>:

> 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
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html