ROWSPAN vs. row group bug example

While developing a program which performs table manipulations, I encountered a situation that wasn't specified in the current HTML specifications: what to do if a cell spans across a row group (or COLGROUP) boundary when the spanning was a non-zero value.

In investigating the problem, I did some tests with Microsoft's Internet Explorer browser (or rather the browser engine) as it was the only browser available to me that I knew honored the HTML 4.x tags THEAD, TFOOT, TBODY, COLGROUP, and COL. The latest release version of Netscape's browser recognizes COL, but insists erroneously that COL must be wrapped in a COLGROUP, but otherwise does absolutely nothing with it.

My attempts to document current behavior led me to construct the following table. The content of the cells describe the behavior of the table in Microsoft's Internet Explorer browser. Subsequent tables contain the same content even when it no longer describes the rendering. The GIF is a screen capture of what the table looks like in Internet Explorer, the browser window constrained so that the image will not exceed 544 pixels wide:

Head span 1 Spans
into
first
line
of
foot
Spans into first line of body Spans into second line of body Head span 1
Foot span 1 Foot span 1
Body span 1 but doesn't block allocation Body span 1
Body span 1 until foot is reached Body span 1 Body span 1

Testing it in Microsoft's Internet Explorer results in a table looking as if it were constructed like this, except that the bold and non-bold content are overstruck upon each other and extra cell divider lines are drawn, as if the cell was doubly spanned twice over. The phantom row only appears if the "but doesn't block allocation" cell in the previous table did not wrap. (GIF):

Head span 1 Spans
into
but doesn't block allocation
first
until foot is reached
line
of
foot

Spans into first line of body Spans into second line of body Head span 1
Body span 1 Body span 1
Body span 1 Body span 1 Body span 1
Foot span 1 Foot span 1

This appears to be symptomatic of a parser which added support for THEAD, TFOOT, and TBODY as an afterthought, greedily allocating cells into the area owned by TFOOT, and afterwards moving the TFOOT to the end of the rendered table, resulting in several rendering errors.

IMO, the proper rendering of that table under HTML 4.0 (which had no restrictions on spanning wrt grouping) should have been equivalent to the table below (GIF):

Head span 1 Spans
to
first
line
of
foot
Spans into first line of body Spans into second line of body Head span 1
Body span 1 but doesn't block allocation Body span 1
Body span 1 until foot is reached Body span 1 Body span 1
Foot span 1 Foot span 1

Further, I believe that under HTML 4.01, which established a new restriction on ROWSPAN=0 and COLSPAN=0 which limited their spanning to the row-/colgroup which contained them, should render such a table as the table below (GIF):

Head span 1 Spans into first line of foot Spans into first line of body Spans into second line of body Head span 1
Foot span 1 Foot span 1
Body span 1 but doesn't block allocation Body span 1
Body span 1 until foot is reached Body span 1 Body span 1

Similar rendering restrictions should be in place for HTML 4.01 when COLGROUPs are used and a COLSPAN of non-zero value spans across that boundary. There are no examples of this here since I have encountered no dramatic failures in Explorer wrt this situation (it behaves as I would expect an HTML 4.0 browser would behave, not as an HTML 4.01 browser).

I welcome comments to this problem and recommend public discussion in ciwah. Reports on behavior of this page in other browsers honoring THEAD, TFOOT, and TBODY are welcome, particularly in the engine to be used in Mozilla 5.0. It is also my recommendation for the browsers to start recognizing the DOCTYPE declaration of HTML documents so that the intended rendering of such tables can be disambiguated.

This page may be modified pending observations and further testing. For the purposes of tracking revisions, this copy is version 1.0, disclosed to the public 1999-11-16 11:30 AM CDT.

Valid HTML 4.0! G. James Berigan