- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2008 10:23:18 -0800
- 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.. http://www.w3.org/TR/2008/WD-timesheets-20080110/#smilTimesheetsNS-CSS 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. ~fantasai
Received on Thursday, 14 February 2008 18:23:19 UTC