Re: Data Table Collections (Research)

2007-09-09 12:43:34 +0200 "Anne van Kesteren" <annevk@opera.com>:
>Sun, 09 Sep 2007 05:34:50 +0200, Leif Halvard Silli <lhs@malform.no>  

[ .. augmentative ... ]
> Another problem, which I think can only be worked around with headers=""  
> (given that headers is not augmentative, I'm not sure about that) is that  

What do you mean by «augmentative» - some kind of inheritance of the @HEADERS value? As far as the algorithm is concerned, @HEADERS tells exactly who the header cells of a particular cell are: The algorithm stops when a headers cell with @headers is found.


[ ... rowgroup => colgroup + col ... ]
> the rowgroup headers should not get the col headers. "Location" etc. is  not 
> an appropriate header for "Day 1 ..." etc. 

As told in the other message, scope="rowgroup" seems here to used wrongly. It must be broadcast the header-cell-presence from left-to-right - it cannot do it from top-to-bottom. Perhaps you could have used scope="colgroup" though: «colgroup: The header cell provides header information for the rest of the column group that contains it.» [1] I think you could do that, if you also added <th scope="col"> on the THEAD cells. This should lead to each new Day cell announcing a new COLGROUP header which would only be valid until a new COLGROUP header would superseed it in the next TBODY. (As Ferg says: COLGROUP/COL and ROWGROUP/ROW only creates 2 level deep headers.[2]) This might be the simplest for you. Since the Day # cells would then be @SCOPE-ed by several cells in the THEAD, then all those cells should apply as its headers. Or else, you could also use @HEADERS too tell who its headers are.

[ ... Doing it with @HEADERS (Reformulations of previous reply in the thread) ... ] 
The meaning of your table would have been more clear (but not as stylish) if it had «Day» as separate column, and then e.g. «Day 3» as a cell in that column, covering all the rows in that rowgroup. (Table 1:)

_Day_|_Location_|_Height_|_Time_|_Remarks_
 Day |  York    |        |      |        
  3  |  Paris   |        |      |        
_____|__Oslo____|________|______|_________

 From this it also becomes evident that «Day 3» can be both a data and a header - and hence, if we say that your table, where «Day 3» is a heading in the TBODY, is simply a recast of Table 1, then your «Day #» cells should have been TD-cells, according to HTML4 - which would also prevent it from picking up the other Day # cells as headers - and also prevent that the TD-cells pick it up twice when we, below, add the Day # cells to the @headers of the Location column cells. (Table 2:)

_Location_|_Height_|_Time_|_Remarks_
_____________DAY_3_[TD]_____________
  York    |        |      |         
  Paris   |  300m  |      |         
__Oslo____|________|______|_________

(You might not see at first, but I think this table bear similarities to Ferg's «[...] most imnportant example in this paper.» [3] That is: this is one variant of Ferg's «indented headers» problem/solution.)

This table version creates (solvalable) problems:  There is no natural, single, header cell for the Day # cells.  And I think this indicate that the Day # cells actually should be the "top" header - semanticly - much like it is in Table 1 above. Which is why I, in the previous letter, proposed to not use any @SCOPE anywhere at all. But to instead use TH-cells for the «geographic» cells in the Location column. And then to add @headers to each TH-cell in the Location column, with the value <th headers="LocationID Day3ID">Oslo</th>. This would, for the cell with "300m" in the Height column, inform us that the cell belongs to «Day 3, Paris, Height».

In addition we would need to say that each Day # cell either has <td headers=""> or that it has <td headers="LocationID HeightID TimeID RemarksID"> - both could be meaningful. (If we don't use @headers on it, and if we use TH-cells in the other cells in the Location column, then e.g. for Day 4 the headers «Oslo, Paris, York» would be listed as amongst its headers - as long as TBODY doesn't have any affect on the header cell interpretation upwards.) 

[ ... which headers does cell with COLSPAN inherit? ... ] 
The fact that Day cells have COLSPAN="4" should lead them to inherit, via the algorithm, both Height, Time and Remarks as well as the headers in the Location column. The alternative would be that it only inherited the TH-cells from the Location column. But we know that downwards, if the Day # cells had been a TH-cell and no affecting @SCOPE was involved anywhere, then all the TD cells of the columns below a Day # cell would inherit it, regardless of which column they were inside - according to the basic algorithm [4]. And it seems logical that it also works upwards - that a cell with colspan="4" would inherit all the headers of all the columns it covers. However, we cannot make use of this in your table. (Except, perhaps, in the first «Day 1» cell row.)

[1] <http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.6>
[2] <http://www.ferg.org/section508/accessible_tables.html#contents_item_6.2.3>
[3] <http://www.ferg.org/section508/accessible_tables.html#contents_item_6.3>
[4] same as [2], but search for «Example Table 1» with explanations
-- 
leif halvard silli

Received on Monday, 10 September 2007 12:47:23 UTC