[html4all] Headers= up

Sat Sep 8 20:25:01 PDT 2007

On 2007-09-09 04:19:58 +0200 Robert Burns <rob at robburns.com> wrote:
> On Sep 8, 2007, at 8:39 PM, Leif Halvard Silli wrote:

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

I think it is necessary to say because of the way the text is written in the spec. Otherwise, it would be better to describe it as having more steps ... 

[...]
>> 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.

I agree witt your «He doesn't need scope for those cells ...» if the reason for you saying so is simply that you think it would be «inpolite» to not interpret the HTML4 this way. ;-) But I must say that this is not in the algorithm text. It could seem like an overlooking. But on the other side, in fact, there is quite little demonstration of how to use TBODY and THEAD in the HTMLT4 spect. An overlooking? To your support speaks that, after all, the THEAD and TFOOT are intended to be always available for sighted users and on print [and there is also print for unsighted ...]. And HTML4 also talks about @headers as a CSS selector ... But. May be this is the spirit of the text. But it isn't the text. It could seem like a gap between what HTML4 has on the table for sighted uses and what it has for unsighted. But, of course, just as it made sense to add rel="nofollow", it would also maked sense to have this interpration. However it isn't in the text. To say that it is in the text, we must perhaps say that it it is a bug that it isn't there ...

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

The wording «reading into» is crucial here :-) It does seem as there has been a lack of interpretation of the text here ... Little exegetic tradition has developed .. ;-) _That_ is the main problem, actually.

>> About @SCOPE in HTML4, the table inspector doesn't get that right
>> either.

[...]
>>      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.

There were many thing I said there. I don't think I said anything wrong about @SCOPE. You may be of the opinon that @SCOPE is not needed in Anne's table, but I think I described @SCOPE correctly, anyhow. Those are a bit independent. 

The point that I wanted to make here was that the Table Inspeector doesn't interpret @SCOPE attributes correctly.

> 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

Well, it depend on what you mean. Yes, in the case of the basic algorithm, this is so.

> 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

What «headerness» exactly is, is hard to tell ... I think this only comes into play when you use the basic algorithm.

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

When a cell is within the «scope» of either a @SCOPE or a @HEADERS then the basic algorithm doesn't come into play. I was discussing the Table Inspector's interpretation of @SCOPE here (I did not even test it for @AXIS yet). 

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

I am not certain what «fair» means. Perhaps this is a shortcoming that HTML4 has. And at any rate, this intepretation needs to be spelt out. Just as there is no point in saying that the Table Inspector shows the HTML5 draft's algorithm, if it in fact uses a more «positive» algorithm, just as much is there little point in insisting that the HTML4 algorithm cannot be read as anything else than «the fair» interpretation of it.

Ferg makes much out this point that the direction search stops. I think this is what it is all about.

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

Whatever that the 4.01 version looks like ;-) Let us not read things into James either ... I want to bring that to the table. However, I must consentrate on the HTML4 algorithm first ...

> [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>
-- 
leif halvard silli