- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 8 Dec 2011 15:48:56 -0800
- 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 UTC