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

Re: [css3-multicol] overflow and paging?

From: Shelby Moore <shelby@coolpage.com>
Date: Fri, 15 Oct 2010 05:37:41 -0400
Message-ID: <74789e8d75f57b585061d056642cdd93.squirrel@sm.webmail.pair.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: www-style@w3.org
> ?
> --------------------------------------------------
> From: "Shelby Moore" <shelby@coolpage.com>
> Sent: Sunday, October 10, 2010 9:30 PM
> To: <www-style@w3.org>
> Subject: [css3-multicol] overflow and paging?
>> Seems to that when a container element on the page has overflow that
>> scrolls vertically (e.g. <div style='overflow:auto'>), then any
>> contained
>> columns should be formatted as if they are paged media with a height
>> equal
>> to the clientHeight of container.
> ...
>> I suppose there are cases where the intention is for the columns to not
>> paginate on clientHeight of the vertically scrollable container, and
>> thus
>> I suggest you need to declare a new style setting, such as
>> paginate-scrollable-contrainer, which defaults to inherit, where the
>> document defaults to the whether the media type is paged.
> I suspect that you want to see something like this:
> http://www.terrainformatica.com/wp-content/uploads/2010/02/print-preview.png
> with only difference that content inside is not scaled but rather has
> dynamic page
> size determined by the container and paginated using that page size [1].
> On the image you see document inside <frame type="pager"> - special
> "behavior"
> attached to the <frame> that shows its content in print-preview mode.
> Decorations of that frame and page boxes inside it is of CSS business.
> But navigation, e.g. "next/previous page(s)" is a business of DOM/runtime.
> I suspect that this is a better way of having columns in HTML/CSS.
> It does not require changes in CSS rather than again flex units and the
> flow
> property (to replace page boxes) [2].
> [1] http://www.terrainformatica.com/2010/02/printing-support-in-sciter/
> [2] http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm


I am in support of a Flexbox layout for CSS, but afaics that is orthogonal
to CSS columns layout model. I don't entirely understand the point you are
making, but it seems like you are saying that existing CSS column layout
model is insufficient. Afaics, the existing CSS column model is
sufficient, we need to add "overflow:inline" and "overflow:block" choices
in order to enable the choice of direction that overflow goes when _BOTH_
the inline (usually width) and block (usually height) directions are
constrain on the multi-column element:


Currently the choice is hardcoded to "overflow:inline" (there is no such
setting yet).

The discussion at the above archive links occurred after the email you are
replying to, and I think the issue and fix is now well understood?


In addition to that improvement above, there is another issue I am raising
in this thread.

When the multi-column element is not constrained in the block direction
(i.e. height), but is contained with some element in its parent hierarchy
which is constrained in the block direction, then a column layout
typography error occurs.  See the diagram here:


That error is not visually detectable in many cases, and thus it the type
of error that could (probably will) proliferate if we don't make it harder
to do wrong. This is why I proposed adding "column-height:constrain" and
"column-height:auto", with "column-height:constrain" as the default.  In
the "column-height:constrain", then the blocking constraint of any outer
container will control the "column row height" and thus prevent the error
from occurring.  Note this is the row height of the columns, not the
height of the content which contains the columns.  The content height will
not be controlled and will still flow freely when the multi-column element
is not itself constrained in the block direction. It is a convoluted thing
to understand, but with that proposed default then it will simply work
correctly.  See the following archive post for the more detailed

Received on Friday, 15 October 2010 09:38:09 UTC

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