W3C home > Mailing lists > Public > www-style@w3.org > October 2011

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

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Fri, 30 Sep 2011 19:45:27 -0700
Message-ID: <BLU165-ds201BB54DCEDA042E54D85CF8F40@phx.gbl>
To: "Alex Mogilevsky" <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: <www-style@w3.org>

-----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)  {

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 Saturday, 1 October 2011 02:45:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:05 UTC