- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 14 Oct 2010 10:58:52 -0700
- To: shelby@coolpage.com
- Cc: Brad Kemper <brad.kemper@gmail.com>, David Storey <dstorey@opera.com>, www-style@w3.org
On Thu, Oct 14, 2010 at 10:54 AM, Shelby Moore <shelby@coolpage.com> wrote: > Thus isn't the spec is wrong then? Should it ever allow the column height > to be greater than constrained height of any outer container, because > afaics the result is typographically erroneous. Note I am not referring to > the non-paging media viewport container (including <iframe> and <frame>). > Can anyone think of a valid need for that? Simplicity and predictability, mainly. We could make CSS attempt to be smarter about how it reacts to ancestor heights, but that would make it harder to predict how it works. It's fairly simple to fix the issue manually with a few "height:100%" rules scattered around. > Thus in any case, none of the above removes the need for the > "column-overflow:inline|block", because if I constrain then the spec > currently always overflows inline (but I need block direction), and the > above code as a work around does not properly limit the column height. The > columns are overflowed (clipped with a vertical scroll bar) in the outer > box but the column height is not restricted to height of the outer box. > Thus a result that is an "abomination" of column typography, as explained > in my prior diagrams :D Correct; we still need a way to force overflow columns to be generated in the block direction instead. ~TJ
Received on Thursday, 14 October 2010 17:59:44 UTC