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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 8 Dec 2011 15:48:56 -0800
Message-ID: <CAAWBYDCS1B-fBP4B277ka2_zkc8L0v1prOhRQiJ0zWOeY6QgJA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Mon, Oct 3, 2011 at 5:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Oct 3, 2011 at 4:58 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> On 10/03/2011 02:36 PM, Ojan Vafai wrote:
>>> 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).
>>
>> I think you missed Andrew's point. Nevermind the syntax, the *behavior* of
>> "display: none"
>> is not actually what you'd want for dynamic show/hide behavior. Because it
>> takes the element
>> entirely out of flow, the hidden element no longer influences layout at all.
>> Which means
>> that by showing/hiding the element, you are adding/removing its influence on
>> the parent's
>> intrinsic sizes, and potentially thus also its size--this is not always what
>> you want.
>>
>> Another side effect is adding/removing its influence on list counters, etc.
>>
>> We don't actually have the right capabilities in CSS to do good dynamic
>> showing/hiding
>> of elements. Visibility: collapse was supposed to do this, but it only works
>> for tables
>> and then only when there are no rowspans/colspans involved.
>>
>> See also the discussion at this thread:
>>  http://lists.w3.org/Archives/Public/www-style/2008Feb/0130.html
>
> Ooh, I'd forgotten about the effects that display:none has on list
> counters.  Dammit, I hate all that magic.  >_<  (I now understand
> *why* that magic occurs, though.)
>
> Okay, so there is still some value in something that acts similarly to
> display:none but without suppressing all that stuff.  Unfortunately,
> your definition for blocks doesn't work for flexbox items - if the
> item is still in the flexbox but not visible, it'll look like a
> double-width packing space if "flex-pack:justify" is set, which is
> undesirable.  (Plus, it needs to be direction-agnostic, or at least
> respond to the flexbox directions, rather than always shrinking height
> to 0.)
>
> I'm not sure what a general definition would look like; I suspect we'd
> need specialized definitions for every display type.  For flexbox, the
> best definition is probably something like "position: absolute;
> overflow: hidden; main-size: 0;".
>
> In any case, until we figure this out more generally, I think Flexbox
> shouldn't have special text for this.

I've just removed the visibility:collapse text.  I hope we can define
another value (either for 'display', 'visibility', or something else)
that makes an element have no rendering behavior but still increment
counters, run animations on descendants, etc.

~TJ
Received on Thursday, 8 December 2011 23:49:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT