Re: [CSS3-box] [css3-tables] visibility: collapse

Boris Zbarsky wrote:
> 
> fantasai wrote:
>> I think smooth and efficient dynamic collapsing behavior makes
>> sense outside of tables as well
> 
> While true, this seems like a rather far-reaching change to make to a 
> specification that is already in CR.  In particular, the process 
> document says[1]:
...
>  > Specifically, block-level elements with "visibility: collapse" should
>  > behave as if their box was zero height with zero vertical padding, border
>  > width, and margins
> 
> There is an issue here (using both this formulation and even more your 
> revised one).  It sounds like you want visibility:collapse to not affect 
> the width of a block.  However, visibility inherits by default.  
> Therefore, given this markup:
> 
> <div style="float: left; border: 1px solid black">
>   <span>Text</span>
>   <table>
>     <col><col>
>     <tr>
>       <td>One</td><td>Two</td>
>     </tr>
>   </table>
> </div>
> 
> The <div> will end up 0px wide, since the <span> and both of the <col>s 
> will have visibility:collapse and collapse horizontally.
> 
> Note that removing the <span> but keeping the text, or removing the 
> <col> elements from the table, would change the rendering, because the 
> text would not follow your inline collapsing rules and because table row 
> and cell collapsing does not affect the table width (while column 
> collapsing does at least in Gecko; Opera and Safari seem to not support 
> column collapsing at all as far as I can tell).
> 
> Really, overloading visibility for the table collapsing behavior was a 
> mistake, imo.  This isn't really something that should be done with an 
> inherited property, and it already has issues with nested tables.  But 
> again, I don't think this is something to be changed at this late stage 
> in the game.

Yeah, those are all good points. Visibility: collapse doesn't even work very
well for the use case it was designed for, because the way it interacts with
rowspan and colspan cells is not something I can imagine anyone wanting.
I can't think of a use case for clipping their content (and possibly also
making it invisible).

I think if we can come up with a good definition for collapsing behavior,
keeping it inherited has some advantages, because you can override it in a
child:

li.collapsed { visibility: css3-collapsed-foo; }
li.collapsed h3 { visibility: visible; }

But on the other hand, it shouldn't inherit from a row into a table cell.
If a row is collapsed, ideally it should leave the rowspanning cell in place,
complete, and visible. That would cause some row heights to shuffle around
and content inside cells to shift up or down, but the result would actually
be useful.

~fantasai

Received on Thursday, 14 February 2008 23:18:27 UTC