W3C home > Mailing lists > Public > www-style@w3.org > February 2008

Re: [CSS21] visibility: collapse on non-table elements

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Feb 2008 10:23:18 -0800
Message-ID: <47B48716.1030206@inkedblade.net>
To: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org

L. David Baron wrote:
> On Thursday 2008-02-14 02:03 -0800, fantasai wrote:
>> Specifically, block-level elements with "visibility: collapse" should behave as
>> if their box was zero height with zero vertical padding, border width, and margins,
>> and inline-level elements with "visibility: collapse" should behave as if their
>> box was zero width with zero horizontal padding, border width, and margins.
>> Furthermore all descendants of a non-internal-table-element with "visibility:
>> collapse"--including descendants that are anonymous boxes--are also treated as
>> if they had "visibility: collapse".
> Is there a compelling use case for this?  Do authors want it for
> some reason?  It's a good bit of work to implement, and it's not
> worth doing that work just to make the property semantics more
> aesthetically pleasing to spec designers.

What prompted me to post it was looking at the Timesheets spec..
They can't find a CSS property that would hide an element without also changing
how all the counters are numbered in elements after the hidden one.

Also a lot of sites like to collapse and uncollapse sections, and doing it
this way would
   a) avoid having to create and reflow their frames every time the section
      is uncollapsed, which is faster
   b) avoid changing the width of the element's shrink-wrap container, if any
   c) not screw around with counters

I'm not particular to using "visibility: collapse" to do it. It seemed like
the right place. But as Boris points out, 'visibility' inherits so it's not
really a good fit.

Received on Thursday, 14 February 2008 18:23:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:34 UTC