W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] overflow and paging?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 14 Oct 2010 10:58:52 -0700
Message-ID: <AANLkTi=4Wyv6M5ZeLRoqJOtkmf9R003YNj3M+CxhO3eW@mail.gmail.com>
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.

Received on Thursday, 14 October 2010 17:59:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC