visibility:collapse revisited

I had occasion to use this feature today, only to find that it is either 
unimplemented or inconsistently implemented in the various browsers. Then 
searching google (both web and groups) I found there was a great deal of 
confusion as to what this feature was supposed to do, and many inconsistent 
answers regarding the question.

I thought this odd since I thought the description of the feature was not 
technically ambiguous at all. The CSS2 spec defines it as follows:

===
This value causes the entire row or column to be removed from the display, 
and the space normally taken up by the row or column to be made available 
for other content. The suppression of the row or column, however, does not 
otherwise affect the layout of the table. This allows dynamic effects to 
remove table rows or columns without forcing a re-layout of the table in 
order to account for the potential change in column constraints.
===

The first point is that the "row or column" is "removed from the display" 
and the space is "made available for other content". So if we have the 
following:

<TABLE BORDER=1>
<TR><TD>R1C1</TD><TD>R1C2</TD></TR>
<TR style="visibility:collapse"><TD>R2C1</TD><TD>R2C2</TD></TR>
<TR><TD>R3C1</TD><TD>R3C2</TD></TR>
</TABLE>

removing the row and making the space available would make the appearance 
would be equivalent to:

<TABLE BORDER=1>
<TR><TD>R1C1</TD><TD>R1C2</TD></TR>
<TR><TD>R3C1</TD><TD>R3C2</TD></TR>
</TABLE>

So far, so good. Now the next point is that this does not "otherwise affect 
the layout of the table". When removing rows, this implies that the browser 
should not need to recalculate the widths of columns. The obvious 
consequence of this is that if the row removed contained wider data in one 
column than in other rows, the column does not get narrower, but there is a 
second consequence of this to do with row spans. The specification 
emphasises this with the indication that this can be used to remove rows 
"without forcing a re-layout of the table in order to account for the 
potential change in column constraints".

Take the following HTML, with a row spanning cell in the first row, and the 
second row collapsed:

<TABLE BORDER=1>
<TR><TD ROWSPAN=2>R1C1</TD><TD>R1C2</TD></TR>
<TR style="visibility:collapse"><TD>R2C2</TD></TR>
<TR><TD>R3C1</TD><TD>R3C2</TD></TR>
</TABLE>

This should also appear the same as the output example above. The spanning 
cell should not span into the third row (that is, the second visible row), 
because this would shift its cells right, thus causing data from column 1 
to go into column 2 and suggesting that a recalculation of the column width 
would be necessary. The alternative would also create a new column 3, which 
would be inconsistent with avoiding changes in the column constraints.

Similarly, the following HTML:

<TABLE BORDER=1>
<TR style="visibility:collapse"><TD ROWSPAN=2>R1C1</TD><TD>R1C2</TD></TR>
<TR><TD>R2C2</TD></TR>
<TR><TD>R3C1</TD><TD>R3C2</TD></TR>
</TABLE>

should result in output equivalent to:

<TABLE BORDER=1>
<TR><TD>R1C1</TD><TD>R2C2</TD></TR>
<TR><TD>R3C1</TD><TD>R3C2</TD></TR>
</TABLE>

Note that the spanning cell from the first row appears opposite the data 
from the second row. There were two possible interpretations here of course 
- one being that the second row should have an empty first column and data 
in the second, and the other being the one I have given, however common 
sense suggests that in situations where row spanning is most likely to be 
used, there is no reason why collapsing the row where the spanning cell is 
introduced should result in the spanning cell ceasing to have relevance to 
the other rows it spans.

The behaviour in the case of columns and column groups would be directly 
analogous.

In the real world, you might have multiple levels of row spanning cells, as in:

<TABLE BORDER=1>
<TR><TD ROWSPAN=3>R1C1</TD><TD>R1C2</TD><TD>R1C3</TD></TR>
<TR><TD ROWSPAN=2>R2C2</TD><TD>R2C3</TR>
<TR><TD>R3C3</TD></TR>
<TR><TD>R4C1</TD><TD>R4C2</TD><TD>R4C3</TD></TR>
</TABLE>

In such a case, it is likely that an author might want to collapse both 
rows 2 and 3, which might be logically treated as one and might reasonably 
be done in one operation. This suggests the need for a ROWGROUP tag which 
could be used to collapse such rows as a group. This would differ from the 
TBODY tag in that row spanning cells could span ROWGROUPs, whereas they 
cannot span TBODYs and ROWGROUPs could be nested. For example:

<TABLE BORDER=1>
<ROWGROUP>
  <ROWGROUP>
   <TR><TD ROWSPAN=3>R1C1</TD><TD>R1C2</TD><TD>R1C3</TD></TR>
  </ROWGROUP>
  <ROWGROUP style="visibility:collapse">
   <ROWGROUP>
    <TR><TD ROWSPAN=2>R2C2</TD><TD>R2C3</TR>
   </ROWGROUP>
   <ROWGROUP>
    <TR><TD>R3C3</TD></TR>
   </ROWGROUP>
  </ROWGROUP>
</ROWGROUP>
<ROWGROUP>
  <TR><TD>R4C1</TD><TD>R4C2</TD><TD>R4C3</TD></TR>
</ROWGROUP>
</TABLE>

__________________________________________________________________________
Troy Rollo, Sydney, Australasia	 		troy@rollo.com
    Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

Received on Friday, 23 November 2001 11:11:02 UTC