[html4all] Headers= up

[Robert Burns]

On Sep 8, 2007, at 8:39 PM, Leif Halvard Silli wrote:

> 2007-09-08 07:30:36 +0200 Robert Burns <rob at robburns.com>:
>> On Sep 8, 2007, at 12:10 AM, Leif Halvard Silli wrote:
>>> On 2007-09-08 06:36:23 +0200 Robert Burns <rob at robburns.com> wrote:
>
> [ .. whwat the HTML4 algorithm says ... ]
>>>> So the HTML 4 algorithm should not be including the Day 1, Day 2,,
>>>> Day3, etc. headers. Though in fairness it also should not include
>>>> the remarks and the other header cell in the THEAD< but I think  
>>>> that
>>>> a generous reading of HTML4 would include those headers.
>>>
>>> We must have the same amount of generousity to whichever spec we   
>>> read ;-)
>>> Perhaps that is the trouble? :-D
>>>
>>> I am not certain you are correct here. What you quoted above is   
>>> merly step
>>> 1 of 5 possible steps in that algorithm.
>>
>> This is the only relevant step in the algorithm for tables  
>> without  headers=
>> or axis=. The entire association happens in that step.
>
>
> Rob, I think actually that algorithm only has *one* step.

Yes, I would basically agree with that assessment. It makes it pretty  
easy to follow, though that succinctness also makes it fairly foggy  
how all of the other intricacies of a table are supposed to work.

> 	HTML4 describes the algorithm in an unordered list. But when Ferg  
> quotes it, he uses an ordered list. I just mention it because the  
> formatting in HTML4 indicates that this list doesn't strictly  
> describe the order in which the algorithm happens. E.g. consider  
> the last list item, about TD cells with @AXIS being treated as  
> header cells.  So all the HTML4 algorithm does is described inside  
> the first item of that list. The other list items merely further  
> explains some other limitations on how what is described in the  
> first list item, is performed. (See full quote of the Algorithm at  
> bottom of this letter.)
>
> 	The first list item describes one limitation of the search: when a  
> data cell is found after a header cell. Fourth list item mention a  
> further limititation, namely that the use of headers="" in a TH  
> cell will also stop the search. Last list item mentions the last  
> limitation, namely that a TD with @axis is also counted as header  
> cell (i.e. it will be counted as a TH cell, I suppose)- and thus,  
> if a data cell is found after the «axis-cell», then the search  
> should stop at the axis cell as well.
>
> Having said this, I now think that the basic Algorithm might not  
> give us what we/Anne want in Anne's table. I think that he needs to  
> use the scope="rowgroup" on the day 1, day 2 cells. And that he in  
> addition must add scope="col" to the THEAD.

No, I don't agree here. He doesn't need scope for those cells because  
they are automatically scoped to the row group because the search  
ends with the header cells at the top of the group (because there are  
data cells beyond that). That's the point I was making with that  
second sentence in the algorithm: "The search in a given  direction  
stops when the edge of the table is reached or when a data cell  is  
found after a header cell.".

HTML 4.01 doesn't really say anything about the THEAD element, but I  
find it hard to imagine the intention is not for those THEAD cells to  
serve as global headings that apply to every data cell in the columns  
the headers span.

With that additional reading into the HTML 4.01 algorithm Anne's  
table isw all taken care of with no scope or headers attributes.

> About @SCOPE in HTML4, the table inspector doesn't get that right  
> either.
>
> 	But first an important thing, namely that HTML4 allows @SCOPE in  
> TD cells as well. Because, as it says: «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.»  As well as «Note the use of  
> the scope attribute with the "row" value. Although the first cell  
> in each row contains data, not header information, the scope  
> attribute makes the data cell behave like a row header cell. This  
> allows speech synthesizers to provide the relevant course name upon  
> request or to state it immediately before each cell's content.»  
> This is important, because, when you put @headers on a TD-cell, it  
> will not stop the basic algorithm from working.
> 	
> 	This last point isn't implemented in the table inspector - if you  
> had <tr><td scope="row">, then the inspector shoul dhave listed  
> this TD-cell as header for rest of the cells in that row. But that  
> doesn't happen.
>
> 	Relating this to Anne's table: He could have used a TD instead of  
> a TH in the Day 1, Day 2 cells. And no @scope or @headers. Then  
> each TD cell would have seen the TH-s in the THEAD.

That is not how I read HTMl 4.01 at all. To me the use of scope or  
axis on a TD cell makes the TD cell behave like a TH cell even though  
it has data in it. It will serve as a heading for other data cell,  
but it doesn't have special properties that another header cell  
doesn't have. Therefore the author's  decision to use <th>some  
heading</th> or <td axis='My heading:' >some heading-like data</td>  
merely depends on whether the cell should be treated as both a data  
cell and a heading cell. I believe the author can also set @abbr on  
the data cell to make it behave as a heading cell. However, in terms  
of Anne's table that doesn't accomplish anything except to include  
the days as part of the data cells for data inquisition.

Like I said, I think a fair reading of the HTML 4.01 algorithm covers  
Anne's table completely without scope= and without headers=. Adding  
those wouldn't break anything it would just make it more explicit  
(though I have misgivings about scope=rowgroup and socpe=colgroup  
because I think they're ambiguous).

The HTML5 algorithms on the other hand is a mess. It happens to work  
with Anne's table simply because Anne's table is very simple and just  
happens to work with the algorithm (as long as scope is set). There  
are other problems though that maybe would break on Anne's table if  
they were implemented correctly. for instance, the HTML5 algorithm  
requires authors explicitly set the scope on  something like the  
headers: location, height, estimated and remarks or else they get  
applied to every cell in the table (even the cells that do not fall  
under them in the same column/columns). I would say there are  
significant problems in every step of the HTML5 algorithm, but James  
implemented something else (something he wanted to read in the  
algorithm perhaps). When we finish this we should rewrite the  
algorithm to at least be as good as the HTML 4.01 version.

Take care,
Rob


[1]: HTML5 algorithm:
<http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? 
rev=1.218&content-type=text/html;%20charset=iso-8859-1#header-and- 
data-cell-semantics>

[2] [ the basic algorithm in HTML4: ]
* First, search left from the cell's position to find row header cells.
   Then search upwards to find column header cells. The search in a  
given
   direction stops when the edge of the table is reached or when a  
data cell
   is found after a header cell.
* Row headers are inserted into the list in the order they appear in the
   table. For left-to-right tables, headers are inserted from left to  
right.
* Column headers are inserted after row headers, in the order they  
appear in
   the table, from top to bottom.
* If a header cell has the headers attribute set, then the headers
   referenced by this attribute are inserted into the list and the  
search
   stops for the current direction.
* TD cells that set the axis attribute are also treated as header cells.
--