[html4all] Headers= up
Leif Halvard Silli
lhs at malform.no
Fri Sep 7 21:51:25 PDT 2007
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 .
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
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
> • 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.
More information about the List_HTML4all.org