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.

Received on Thursday, 8 December 2011 23:49:55 UTC

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