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

I also prefer #2

In fact I’ve implemented it for all layout managers (flow) I use.

The only challenge is for flow:”template”  (a.k.a. Grid Module). 
It appears that we need visibility: collapse | collapse-x | collapse-y there.

-- 
Andrew Fedoniouk

http://terrainformatica.com



From: Ojan Vafai 
Sent: Tuesday, October 04, 2011 6:17 PM
To: Andrew Fedoniouk 
Cc: Alex Mogilevsky ; Tab Atkins Jr. ; www-style@w3.org 
Subject: Re: [css3-flexbox] visibility:collapse on flexbox items

I see the benefit of something like visibility:collapse, but I don't see why it should be restricted to tables/flexboxes.  

We could instead:

1. Create a new value for visibility, collapse-for-real (with a better name) that does the collapse behavior described below for all display types.
2. Make visibility:collapse do the behavior described below for all display types.

If we could get away with 2 without backwards compatibility issues, I'd prefer that.

Ojan


On Mon, Oct 3, 2011 at 7:58 PM, Andrew Fedoniouk <andrew.fedoniouk@live.com> wrote:

  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.
  Example: 

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

  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”>
      <option>Yes</option>
      <option>No</option>
  </input>

  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

  http://terrainformatica.com




  From: Ojan Vafai 
  Sent: Monday, October 03, 2011 2:36 PM
  To: Andrew Fedoniouk 
  Cc: Alex Mogilevsky ; Tab Atkins Jr. ; www-style@w3.org 
  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 http://www.whatwg.org/specs/web-apps/current-work/#hidden-elements).


  On Fri, Sep 30, 2011 at 7:45 PM, Andrew Fedoniouk <andrew.fedoniouk@live.com> wrote:


    -----Original Message----- From: Alex Mogilevsky
    Sent: Friday, September 23, 2011 3:36 PM
    To: Tab Atkins Jr.
    Cc: www-style@w3.org
    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)  {
    visibility:collapse;
    height:40px;
    }

    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 {
    visibility:visible;
    }

    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>
    <html>
    <head>
      <title></title>
      <style>
        tr:nth-child(1) { visibility:collapse; }
      </style>
    </head>
    <body>

    <table border>
      <tr><td>longlonglonglonglonglonglonglonglonglong</td></tr>
      <tr><td>short</td></tr>
    </table>

    </body>
    </html>

    Cheers.

    -- 
    Andrew Fedoniouk

    http://terrainformatica.com