[html4all] Headers= up

[Leif Halvard Silli]

On 2007-09-08 06:15:31 +0200 Robert Burns <rob at robburns.com> wrote:

> Hi Leif,
> 
>  From a cursory glance at these, they do not seem to me to implement  the 
> algorithms as listed in the respective recommendations. That's  not really 
> that important,

If you can pin it down and explain to james, then you should.

 ...
 
> The goal for the HTML WG is simply to find an algorithm that works  well in 
> the absence of explicit 'headers' attributes regardless of  whether that 
> draws on HTML 4.01 or the current draft. However, the  problem now is that 
> James's implementation of the HTML5 algorithm  glosses over its deficiencies 
> to make it look like its adequate  already [2].

Can you you pin this down also? 
 
> The HTML4 algorithm is actually quite short and quite easy to follow.  James 
> interpretation looks way off to me, but that's not really that  important. 

Yes it is important,

> It's the interpretation of the HTML5 algorithm that tries  to make it look 
> like we have an adequate algorithm that's the  problem.  In the absence of 
> scope (if we take this literally) the  header cell is actually supposed to be 
> assigned to every data cell  (which basically renders the header cells 
> useless). The HTML5  algorithm says that

What do you mean here by «supposed to be assigned to every data cell»? And why is it useless?

> "If the header cell is not in the first row of the table, or not in  the 
> first cell of a row, then don't assign the header cell to any  data cells."
> 
> Anyway, I think at this stage we should largely throw out the  different 
> algorithms (and especially comparisons of the different  algorithms ) and 
> work towards refining an algorithm that works well.  We should also be clear 
> that the James implementation of the HTML5  algorithm does not reflect the 
> current draft, otherwise we'll be  lulled into thinking the current draft is 
> adequate.

Yes, this must be documented very well! And then he should correct it.
 
> To get an algorithm that works well I think we also need to rethink  the 
> 'scope' attribute. Right now it has the values: 'col',  'colgroup', 'row' and 
> 'rowgroup'. However this is confusing because a  column heading will 
> typically either have a 'col' value or a  'rowgroup' value, so the meaning or 
> 'row' and 'rowgroup' actually  have no relation. I think the HTML4.01 
> approach is better in that a  corner header cell may apply either to the 
> column or the row or both.  Row group and column group just add to the 
> confusion. So here's how I  think the algorithm should be constructed:
> 
>   • header cells in the thead (or even all cells in the thead) should  apply 
> to all cells that they column span
>   • header cells in a tbody should apply to all remaining data cells  
> beneath them that the header cell colspans and all remaining data  cells to 
> the right of them (left of them for dir=rtl) that the header  cell rowspans 
> subject to the following qualifications
>      - whenever a run of data cells reaches another header cell the  
> association should stop
>      - to associate header cells (and therefore the data cells that  they 
> associate with) with other header cells the headers attribute  should be 
> used. This would for example accomplish the same thing for  rows that can be 
> accomplished without headers= for columns using the  thead element. For 
> example if an author includes a column of row  header cells at the beginning 
> of a table and then includes several  other columns of row header cells that 
> will apply only to data cells  in the rows locally according to this 
> algorithm, the the use of  headers='' will allow associating different groups 
> of data cells and  control scoping better and more clearly.
>      - scope of 'col' limits that to only the cells beneath them and
>      - scope of 'row' limits that to only cells to the right of them  (left of 
> them for dir=rtl).
>      - the rowgroup and colgroup values for scope should be  eliminated except 
> for legacy reasons. They create confusion because  they overlap with an 
> author that might want to break the table into  arbitrary groups of data 
> cells broken by a new band of one or more  consecutive header cells. If these 
> authoring techniques are at cross  purposes its just more confusing for 
> authors.
>   •  axis should be rethought because I don't think its clear enough  from 
> HTML 4.01 and common usage or implementations what it means
>   • with this approach headers= would be mostly reduced to an  attribute on 
> TH cells that would automatically associate the TH cell   and all of its 
> associated TD cells with another TH cell.
> 
> Those are my thoughts, I support I should put something more formal  
> together, but I thought I'd see what users on this list think.


This desires more thinking than I can do right in this moment. But  I want to stress how important it is that we get the HTML4 algorithm rightly understood. And also, of course, that the HTML5 algorithm, as proposed, is righlty implemented in the inspector. I think we need to do do that first of all. And then we can suggest improvements.
-- 
leif