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: Tue, 12 Oct 2010 12:40:25 -0700
Message-ID: <AANLkTimaAfFvB=fWPcossrjNmyHWu5O8etDPo0bFfepx@mail.gmail.com>
To: shelby@coolpage.com
Cc: David Storey <dstorey@opera.com>, www-style@w3.org
On Tue, Oct 12, 2010 at 11:25 AM, Shelby Moore <shelby@coolpage.com> wrote:
> Tab Atkins wrote:
>>  If
>> the height is constrained, then overflow always results in generating
>> new columns in the "after" direction.  From the spec, section 8.2: "A
>> declaration that constrains the column height (e.g., using ?height?)
>> must be honored, if possible. ... In continuous media, columns that do
>> not fit within the multicol element are added in the inline
>> direction."
>
>
> But the spec is apparently ambiguous as to what to do when the _BOTH_ the
> height and width are constrained.
>
> As per my tests in all browsers (IE6, FF3.5.x, FF3.6.0, latest Chrome),
> when column-width, width, and height are all set, then the overflow:auto
> flows out the bottom, i.e. no extra columns are created.

I'm not sure how you're seeing that result.  On both FF and Chrome on
my Linux and Windows machines, the following style:

div {
	-moz-column-width: 50px;
	-webkit-column-width: 50px;
	width: 200px;
	height: 100px;
	border: 1px solid black;
	-moz-column-rule: 1px solid black;
	-webkit-column-rule: 1px solid black;
}

...results in many 50px-wide columns being created and placed to the
right.  Switching that to column-count:3 gives a similar rendering.
Specifying both -width and -count together give me the same rendering
as one or the other (Chrome and FF differ on which they feel like
honoring, which means a bug in at least one of them).

The only way I can get columns to grow vertically is to keep height:auto.


> But alas, without any pagination, so thus is not ideal. Given that the
> spec is ambiguous on the case of simultaneous height and width constraint,
> I suppose we are free to specify now what should be done?  Normally we
> would adopt what all the browsers are already doing? Thus we would have to
> add a non-default setting for column-overflow:paginate?  But that is a
> shame, as I think the default should be to paginate.

It's not ambiguous.  It's defined.


>> This is the
>> situation you're running into.
>
> No my situation is to constrain both the height and the width.

Ah, that wasn't clear to me.  You were describing a situation where
you had a set number of columns that were growing too tall, which
afaict is only achievable if the height of the multicol element is
unconstrained.


>> will indeed
>> require a new mode-switch, something like "column-overflow: inline |
>> block" to specify where overflow columns get created.
>
> Okay, so if block is in the same direction as column rows, then it means
> there must be pagination, because maximum column height has to be
> respected from section 8.2: "A declaration that constrains the column
> height"?
>
> So thus block is equivalent result in to my suggestion
> column-overflow:paginate? (I like it, more orthogonal then my paginate
> suggestion)

Yes, roughly.  It would make the columns be equal to the block's
height, with more sets of columns placed below.  It's then up to the
overflow method to decide how to display that.

~TJ
Received on Tuesday, 12 October 2010 19:41:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:32 GMT