Re: [css3-flexbox] visibility:collapse on flexbox items

Flexboxes inherit many properties of tables, namely: flexibility, intrinsic widths calculation, BFC, etc.
When in-place they are used instead of tables (that still used for layout purposes due to their unique properties).
We should have something like visibility:collapse if we want to provide alternative to <table>s.

To treat visibility:collapse as such a display:none is conceptually wrong as we cut out many 
useful cases.

visibility:collapse is conceptually different from display:none in these respects:
  1.. visibility:collapse element has position but block progression dimension is set to zero; 
  2.. visibility:collapse element takes space but only in orthogonal dimension (to BPD). 
  3.. children of visibility:collapse elements are not excluded from rendering tree – content of visibility:collapse container is measured normally.

<ul style=”flow:vertical; border:1px solid; width:max-intrinsic;”>
   <li style=”visibility:collapse;”>longlonglonglong</li>

the above UL should be rendered with width equal to the width of “longlonglonglong”
string but only “short” should be visible.

So if we want to reveal first item (e.g. with animation) the width of the UL will not change.

Here is practical sample from one of UIs:

Imagine input element like this 

<input type=”toggler”>

This element should work as checkbox: on click it should show either “Yes” or “No”.
It should not change dimensions while switching – width should be of its longest option. 

Without visibility:collapse last requirement is not naturally achievable by CSS means (if not to use tables here).
And using fixed width of the toggler is not an option here due to i18n issues.

Andrew Fedoniouk

From: Ojan Vafai 
Sent: Monday, October 03, 2011 2:36 PM
To: Andrew Fedoniouk 
Cc: Alex Mogilevsky ; Tab Atkins Jr. ; 
Subject: Re: [css3-flexbox] visibility:collapse on flexbox items

Now that I understand the behavior of visibility:collapse in tables, I don't think we should extend the behavior elsewhere. We should just have visibility:collapse work the same way on flexboxes as it does elsewhere (i.e. like visibility:hidden). Otherwise, visibility:collapse becomes this complicated beast that noone can use because the rules are different for each display type. 

I agree with Alex that we need a way to show/hide items without wiping their display property, but we already have that with the "hidden" attribute (see

On Fri, Sep 30, 2011 at 7:45 PM, Andrew Fedoniouk <> wrote:

  -----Original Message----- From: Alex Mogilevsky
  Sent: Friday, September 23, 2011 3:36 PM
  To: Tab Atkins Jr.
  Subject: RE: [css3-flexbox] visibility:collapse on flexbox items


    It seems that if "visibility:collapse" is targeting the same kind of
    dynamic scenarios as in tables, it should behave exactly as "display:none"
    in flexbox (no extra spacing in justify). It doesn't seem super useful then
    - but it does make it easier to show/hide items without wiping their
    'display' property (your favorite inner/outer display issue).

  In fact 'visibility:collapse' should not and does not
  behave as 'display:none'.

  Consider flow:horizontal container that has two children.
  Suppose that one of these children is declared as

  .hor-child:nth-child(1) {  height:20px; }

  .hor-child:nth-child(2)  {

  then height calculation of the container shall take height of collapsed
  element into consideration (so container will be 40px height).
  So when at some point you will say:

  .hor-child:nth-child(2).expanded {

  the container will not change its height.

  The 'collapse' means collapse block progression dimension of the element
  keeping other dimension intact. That is how visibility:collapse;
  works in tables.  tr {visibility:collapse;} and tr {display:none;} produce
  different results. Here is an example (use anything but not WebKit
  as it has bug here):

  <!DOCTYPE html>
      tr:nth-child(1) { visibility:collapse; }

  <table border>



  Andrew Fedoniouk

Received on Tuesday, 4 October 2011 02:59:13 UTC