Re: Data Table Collections (Research)

2007-09-09 23:10:40 +0200 James Graham <jg307@cam.ac.uk>:
> Robert Burns wrote:
>> On Sep 9, 2007, at 8:40 AM, Anne van Kesteren wrote:
>>> Sun, 09 Sep 2007 12:43:34 +0200, Anne van Kesteren <annevk@opera.com> 

>>> At some point in this thread I admitted that scope= was indeed redundant 
>>> in my table per the algorithm given in 
>>> http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3 HTML4. However, the 

I think you only agreed to a bug in the Table Inspector with regard to its interpretation of the basic HTML4 algorithm. ;-)

>>> reason the scope= attribute was included was not because data cells would 
>>> not be associated with header cells but because header cells would 
>>> otherwise be associated with the wrong headers. (I misremembered that.) 
>>> For instance, following the algorithm of HTML4 in the absense of scope= 
>>> the "Day 2 ..." header would get "Day 1 ..." as header.
         
Thanks for the explanation. So, by using SCOPE="rowgroup" you meant to keep the scope of the @SCOPE inside that particular rowgroup (i.e. inside that particular TBODY) - thus neither TH-s or TD-s of the above TBODY-s was meant to become affected. I understand the thinking. It could be that it could be made to work that way, as it makes much sense - and I almost jumped on it. And I see that Table Inspector interprets it that way. But,

[... meaning of SCOPE="rowspan" ... ]

I just want to ask first: can scope=rowgroup be used both top-to-bottom as well as left-to-right? 

(Table Inspector seems to think so. It also doesn't make a difference between <tr><th scope="row"> and <tr><th scope="rowgroup">. Furhter more, it also accepts <tr><th scope="rowspan">. And - it interprets _all these_ as SCOPE="ROWGROUP" - read on.) 

And is is affected by the fact that you use colspan="4", at all? The examples in HTML4 with scope="colGROUP" spans from top to bottom - it works downwards. Influenced (I think) by how CSS selectors works, it could seem natural to be wanting to apply <tr><th scope="colgroup">, in order to make sure the cell does not affect the colgroup to the right of the first colgroup. But this is not how it works in HTML4, as much as I can see. Colgroup only works downwards. Scope="col" also only works downwards. And SCOPE="COL" cannot be used to scope anything that is more than one column wide. Likewise, SCOPE="ROW" only works left-to-right (in LTR-tables). And it can only scope rows that cover one row.
	
But - SCOPE="ROWGROUP" - that's an oddball. Neither Ferge or HTML4 actually provides any example of how it could be used. But Ferg seems to make the assumtion, that it works like ROW - from left-to-right. At least he links it with ROW: «[...] two levels: colgroup and col, or rowgroup and row.» [1] You, however (and thus the Table Inspector too), uses it from insertionpoint-to-bottom, inside a rowgroup - as well as from left-to-right (at least the Table Inspector does). I think Ferg's thinking is that if you make a cell which covers all the rows inside a rowgrop (that would be a <th rowspan="0" scope="rowgroup">), then this cell would work as header, from left-to-right in the entire rowgroup. I.e. this is for scoping rows that covers more than one row.
	
Usecase that defend my interpretation: 
When we just make use of the simple algorithm, then a cell with <tr><th rowspan="0"> will, in fact, become header cell for all the cells to the right of that cell - inside that TBODY/THEAD. But, if a certain TD in a rowgroup (TBODY) is being scoped with <TH scope="col">, then - as much as I understand it - any TH-cells in the first column will not be seen as headers for that TD (because the basic algoritm does only step in when there is no trace of @SCOPE on the cell - and the cell also doesn't have a @HEADERS). Thus, in such a case, <tr><th rowspan="0"> will not be see by that TD-cell - unless we apply <tr><th rowspan="0" scope="rowgroup">.

But let's imagine for a second that what you do is actually correct use. 
Then, I would still question whether the Day X cells should scope more than the first column in the table. Because, as Ferge says: «The COLSPAN attribute has no bearing on the effect of the SCOPE attribute.» [2] Thus, how could your <the scope="rowgroup"> cover the entire width of the table - as Table Inspector thinks it does? If this should be possible, then the scope="rowgroup" would have to be a TBODY equivalent of scope="colgroup" - which would mean that it was affected by the COLGROUP element. And hence, the only reason why it works here, would be [as Ferg says about the HTML4 example of how scope="colgroup" works] because a TABLE always has one default COLGROUP - regardless of whether the COLGROUP element is present or not. But is there anything that hints that this is how scope="ROWGROUP" works? Rather, how it works is decided by the rowgroup = the TBODY, and not by the COLGROUP. An this - btw - is one more argument that speaks for my interpretation, because, if it worked downwards, then it would actually mess with how scope="colgroup" works. You would have to make sure that you did not define groups that clashed with how COLGROUP worked - you would have to add COLGROUP elements if you wanted to let it cover e.g. 1 column, or 2 columns or 3 columns etc. OTOH, if scope="rowgroup" should work downwards, *without* being affected by the COLGROUP element, then that would mean exactly what I said above: namely that it could only cover _one_ column - regardless of your colspan="4".

As it is, HTML4 desperatly needs scope="rowgroup" to mean «left-to-right», else the use case I described above would not be coverd. It would perhaps be nice, if scope="rowgroup" could be used both downards (somehow) as well as left-to-right, but in HTML4, we are not there, I think. (But, as used we are to think in CSS terms - CSS-selectors, and with the wording in HTML4 about ROWGROUP: «for the rest of the row group that contains it»  [3], and the lack of code examples in the spec(!), it is no wonder that this can be misunderstood.)

The effect of scope="rowgroup" only working left-to-right, would also be that you cannot use scope="rowgroup" the way you did in order to hinder that the Day # cells see the other Day # cells as their headers. 

So, in my opinion, you are currently using @scope in an invalid way - meaning that your table should just be interpreted according to the HTML4 basic algorithm, therefore. The TH-cells with Day # should actually have been in a separate column, before Location column. Then, according to the algorithm, screen readers would have found _that_ cell first, and thenafter the corresponding header cell in THEAD. Perhaps it is possible, in Opera, to use CSS to make such a  TABLE _look_ as the way you have currently made it, without affecting the actuall markup that I herby suggest you used?

Another method that doesn't change the markup (very much), could be this: CHange the leftmost cells (in the Location collumn) into TH-cells. Then, in addition, add a headers="Location day1", headers="Locationn day2" in each of those location TH-cells - in accordance to which day they belong. In addition, change the Day # cells from TH-cells to TD-cells. Then, according to the algorithm, each TD cell will first look to the left and find the location-cell - and will also include the HEADERS="location day#" reference. (Perhaps, it would be defendable to omit the "location" id.) Then it will look upwards - and find the corresponding header cell in the THEAD. To change the mark-up even less, you could add the AXIS-atribute to the cells in the Location column, as such cells are - according to the algorithm - «treated as header cells». (You would then only need to change the Day # cells into a TD-cell.)

[ ... algorithm only when SCOPE/HEADERS isn't used? ..]     
                                                
Btw, in your previous letter  [4], you said that «Another problem with the algorithm in HTML4 is that it suggests it should  only be taken into account when there's no scope= or headers= information  in the table. (It's not augmentative.)». I don't think this statement is in accordance with the HTML4 algorithm, which says «In the absence of header information from either the scope or headers attribute [...]» [5]. So, a table can have cells with both @headers and @scope - but if the focused cell is not affected by any of them, then the basic algorithm will apply. For instance, for a cell like <td SCOPE="col"> or <th scope="col"> we must use the HTML4 algorithm in order to find out who its header cells are.

>>> I suppose this could be circumvented by requiring that headers for header 
>>> cells are directly adjacent to those cells.

I.e. if a TH-cell has no TH-cell above itself, then it should not look for header cells anywhwere else in this or any other rowgroup - with the exception of the THEAD and TFOOT, where it definitely should look? (Se my comment to Rob below:)

>> The HTML4 algorithm is for associating header cells with data cells. It 
>> doesn't associate header cells with header cells so scope= is not necessary 
>> in your
> 
> I don't think that's at-all clear from the HTML 4 spec though I agree it can 
> be read that way.

I think it is clear that the HTML4 algorithm is _also_ for TH-cells - see my note above about finding the headers for a <TH scope="col"> above.  What we need to work out, though, is the effect of multiple TBODY-s. Should a TH-cell look for its header cells in TBODY-s that appears before the TBODY which itself is inside? 

> In general, having long debates about the exact intent of 
> the HTML 4 spec isn't really an interesting way to spend time so, unless 
> their are clear bugs (some examples of which have been raised already), I 
> don't plan to change the "HTML 4" algorithm in the table inspector. However I 
> am interested in hearing about ways to improve heading association and will 
> endevour to implement reasonably-detailed suggestions for algorithms as 
> separate options for people to try.

I agree with your goal. But I do think it is important that all the algorithm implementation in the Table Inspector are bug free  - including the HTML4 algorithm implementation - else it is difficult to discuss improvement. You can do the programming, and we can hopefully can do a little of the thinking. ;-)

[1] <http://www.ferg.org/section508/accessible_tables.html#contents_item_6.2.3>
[2] <http://www.ferg.org/section508/accessible_tables.html#contents_item_6.2.5>
[3] <http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.6>
[4] <http://www.w3.org/mid/op.tyduqwf464w2qv@annevk-t60.oslo.opera.com>
[5] <http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.4.3>
-- 
leif halvard silli

Received on Monday, 10 September 2007 06:16:10 UTC