Question about table heading information in HTML 4

http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.4.3
gives an algorithm for finding heading information, but it seems to be 
vague on some points.

Questions:
1. "In the absence of header information from either the scope 
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-scope> 
or headers 
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-headers> 
attribute, user agents may construct header information according to the 
following algorithm."
Does this statement mean that if there IS either scope or headers, then 
the user agent should only pick up on those headers and nothing else? 
What happens if there is a conflict - ie, if the headers attribute lists 
only the column header, but there is a row header with a scope of row? 
Is that row header still a header for the cell in question?

Why this matters:
In Aurelien Levy's table example page at 
http://www.fairytells.net/table_test_case/
there is a test case called "complex table with th and headers/id"

For that test case, the 2nd row is made up of th elements. They have 
headers that say what is their column header. The intent is that "2" 
would only have a column header, but not a row header. However, since 
there is no scope used, it seems like the row header for the th cell 
with data "2" would be the th cell with the data "1". In this particular 
case, the correct thing to do is to only use the IDs specified by 
headers and NOT look for row headers. But is this true in general?

Code:

        <table>
           <tbody><tr>
             <th rowspan="2" id="h">Homework</th>

             <th colspan="3" id="e" headers="h">Exams</th>
             <th colspan="3" id="p" headers="h">Projects</th>
           </tr>
           <tr>
             <th style="" id="e1" headers="e">1</th>
             <th style="" id="e2" headers="e">2</th> <--This is the cell 
in question, is the previous th a header for it?
             <th id="ef" headers="e">Final</th>

             <th id="p1" headers="p">1</th>
             <th id="p2" headers="p">2</th>
             <th id="pf" headers="p">Final</th>
           </tr>
           <tr>
            <td headers="h">15%</td>
            <td headers="e e1">15%</td>

            <td headers="e e2">15%</td>
            <td headers="e ef">20%</td>
            <td headers="p p1">10%</td>
            <td headers="p p2">10%</td>
            <td headers="p pf">15%</td>
           </tr>
        </tbody></table>


2. "First, search left from the cell's position to find row header 
cells. Then search upwards to find column header cells."
How is this algorithm implementable given the structure of the DOM? 
Searching to the left or upwards does not really make sense because cell 
and row indices do not correspond to the x,y grid. Let us say that we 
have the following structure:

Homework    Exams    Projects
1    2    Final    a    b    c


Homework = row 0, cell 0
Exams = row 0, cell 1
Projects = row 0, cell 2
1 = row 1, cell 0
2 = row 1, cell 1
final = row 1, cell 2
a = row 1, cell 3
b = row 1, cell 4
c = row 1, cell 5

If you naively use row and cell for your y and x, you get into trouble. 
It looks like 1 is below Homework, 2 is below Exams (happens to be 
right), and Final is below Projects.
But you can't know compute the actual layout of the table unless you 
start from the very first cell and build up a model of the table 
structure, keeping track of when one cell has expanded beyond the size 
of a normal cell and is currently occupying the space of multiple cells. 
So is there a more practical algorithm for doing this?

-Charles

P.S. The WHATWG HTML5 has an expanded algorithm description:
http://www.whatwg.org/specs/web-apps/current-work/#header-and-data-cell-semantics
However, they talk of using "the coordinate of the slot", ie, the true 
x,y coordinates. So the problem of computing that in an efficient manner 
is still an issue.
And since they are missing the headers attribute, it does not answer the 
first part of my question either.

Received on Sunday, 17 June 2007 13:02:45 UTC