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 <ojan@chromium.org>
> *Sent:* Monday, October 03, 2011 2:36 PM
> *To:* Andrew Fedoniouk <news@terrainformatica.com>
> *Cc:* Alex Mogilevsky <alexmog@microsoft.com> ; Tab Atkins Jr.<jackalmage@gmail.com>;
> 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>**longlonglonglonglonglonglonglo**nglonglong</td></tr>
>>   <tr><td>short</td></tr>
>> </table>
>>
>> </body>
>> </html>
>>
>> Cheers.
>>
>> --
>> Andrew Fedoniouk
>>
>> http://terrainformatica.com
>>
>>
>>
>