Re: Spanning rows in HTML3 tables

yuri@sq.com
Fri, 2 Dec 1994 16:56:36 -0500


Date: 	Fri, 2 Dec 1994 16:56:36 -0500
From: yuri@sq.com
Message-Id: <9412022156.AA05536@sqrex.sq.com>
To: www-html@www0.cern.ch, jenglish@crl.com
Subject: Re: Spanning rows in HTML3 tables


Joe English writes:
 
> 
> Many other table schemes -- TeX, tbl, and (most importantly) 
> DSSSL expect to see empty cells where spanned rows would 
> appear; in other words:
> 
>     <table border id=ex2>
>     <tr>
> 	<td rowspan=2> row 1, col 1</td>
> 	<td rowspan=1> row 1, col 2</td>
> 	<td rowspan=2> row 1, col 3</td>
> 	<td rowspan=1> row 1, col 4</td>
>     </tr>
>     <tr>
> 	<td></td>	<!-- r2 c1 empty, overlapped by r1c1 -->
> 	<td> row 2, col 2</td>
> 	<td></td>	<!-- r2 c3 empty, overlapped by r1c1 -->
> 	<td> row 2, col 4</td>
>     </tr>
>     </table>
> 
> I think (but am not sure) that CALS and ICADD tables
> expect either empty cells in the content or column starting
> numbers in attributes to handle this:
> 
>     <tr>
> 	<td colstart=2> row 2, col 2</td>
> 	<td colstart=4> row 2, col 4</td>
>     </tr>
> 
> 
> Is it possible to change the HTML 3 table semantics
> to expect empty cells and/or require a colstart attribute?
> 

ICADD asks for optional COLSTART and ROWSTART attribute 
values and does not expect empty cells where spans might
overlap -- to a great extent because it believes that tables
might be pivotted or otherwise reconfigured at any time.


> I ask because if the DSSSL table model ends up in 
> DSSSL-Lite, the burden of computing spanning rows
> will be on *stylesheet authors*.  I'm sure it's possible 
> to write Scheme code to do this for the current 
> semantics, but I'm also sure it's not easy...  
> COLSTART attributes and/or empty cells make 
> the problem much more tractable.
>

A problem with the empty cells model is that they imply
that the table really is intended to be used *only* in
this way...that is, that the data is not expected to
be reconfigured into other presentation forms.

> It may also make converting other table formats into
> HTML easier, since the conversion software won't
> need to figure out when cells must be omitted.
> It may also make it easier for other browsers to
> implement tables.

Perhaps this is a six of one/half doz of other situation.

However, it still seems to me that the current model is
cleaner, and, if needed, a filter can generate the empty
cells -- temporarily, for whatever processing is needed --
more easily than a processor can decide that an empty
cell with some kind of attributes can be ignored.


Yuri Rubinsky