W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2006

[whatwg] Comments on the table model

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 22 Nov 2006 23:11:59 +0200
Message-ID: <AA4D0237-B7E7-4D31-BE26-E352895923F3@iki.fi>
"Cell can either be data cells or header cells."

Incongruent singular and plural.

"Not every row is necessarily in a row group."

What terminology is suggested for consecutive rows that are not in a  
row group? (I have tentatively used "implicit row group".)

"Not every column is necessarily in a column group."

Noting that in HTML 4.01 terminology, in the absence of explicit  
column groups, there is a single implicit column group.

"A cell cannot covers slots that are from two or more row groups or  
two or more column groups"

I agree about row groups, but Firefox 2.0, Opera 9.02, Safari 2.0.4  
and IE7 allow cells to span over column group boundaries interoperably.
http://hsivonen.iki.fi/test/wa10/tables/colspan-over-colgroups.html

The algorithm for establishing explicit columns and column groups  
does not cover the (non-conforming) case of <col> elements as  
children of <table> (via XHTML or DOM manipulation). From the  
behavior of Firefox 2.0, Opera 9.02 and Safari 2.0.4, I suggest that  
consecutive <col>s as children of <table> for an implicit row group.  
(And I don't see why that couldn't even be conforming.)

Step 14. "Otherwise, run the algorithm for ending a row group."  
implies that there are implicit row groups. :-)

In step 17., how could y_max >= y_start not hold?

It seems to me that the "algorithm for ending a row group" extends  
the cells in the "list of downward-growing cells" from y_current to  
y_max. This seems wrong. Browsers clip cells whose rowspan is still  
pending when a row group ends. It follows that the y_max established  
in one row group should be reset when a new row group starts.

The steps dealing with parsing colspan and rowspan do not dictate the  
algorithm like the steps for parsing span or col and colgroup do.

Personally, I found it easier to handle cells with rowspan='0' by  
setting them to span until row infinite (that is the max value of  
int) as opposed to having a separate flag. For each cell, I keep  
track of the start column, start row, the column until which the cell  
spans and the row until which the cell spans. I put all cells whose  
rowspan != 1 in a set that I call cells in effect. When a row ends, I  
remove all cells that no longer span onto the next row from the set.  
When a row group (which can be implicit) ends, it is an error to have  
cells in the set whose spans-until-row is not infinite. When a new  
row starts, I sort the set of cells in effect by the start column so  
that the sorted list can easily be searched for the next free slot by  
examining each cell in effect at most once per row. Note that keeping  
track of the extent of each cell in effect makes it unnecessary to  
keep track of overall y_max. (My algorithm works without actually  
instantiating a data structure for the slot grid, so memory  
requirements are relative to the number of cells in effect and to the  
number of elements that have caused columns to be established and not  
to the number of slots in the table.)

I notice that, unlike discussed previously, the table model does not  
make it an error if a column or row does not have any cells starting  
on it. Also, having x_max grow over what was established by explicit  
columns is not an error. Nor are ragged tables in any way shunned  
(except when there are empty explicit columns).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 22 November 2006 13:11:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC