Re: [css3-multicol] overflow and paging?

> 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.


Add overflow: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.


Where in the spec is it defined what to do for the case above, with
overflow:auto added?

Afaics, the spec says nothing about the simultaneous height and width
constraints.

===============
The following only applies when the height is unconstrained:

http://www.w3.org/TR/css3-multicol/#the-number-and-width-of-columns

"3. The number and width of columns

Finding the number and width of columns is fundamental when laying out
multi-column content. When the block direction is unconstrained and no
column breaks are added through style sheets, these two properties
determine the outcome"


================
Are you refering this, but doesn't it apply only when the height is
unconstrained (in section 3)?

http://www.w3.org/TR/css3-multicol/#pseudo-algorithm

"(32)      N := floor((available-width + column-gap) / (column-width +
column-gap));
(33)      W := ((available-width + column-gap) / N) - column-gap;"


=================
But the following only applies when the height is constrained:

http://www.w3.org/TR/css3-multicol/#overflow-outside-multicol-elements

"8.2. Overflow outside multicol elements

Content that extend outside column boxes at the edges of the multi-column
element is clipped according to the ‘overflow’ property.

A multicol element can have more columns than it has room for due to:

    * Constrained column height. A declaration that constrains the column
height (e.g., using ‘height’) must be honored, if possible. In paged
media, the column height is constrained by the size of the page.
    * Explicit column breaks. Explicit column breaks may create more
columns than there is room for inside the multicol element.

In continuous media, columns that do not fit within the multicol element
are added in the inline direction. "



>>> 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.


I mentioned in nearly every post in this thread that I was having to
scroll the container (not the page) up and down.  There can't be vertical
scroll bars on the container if the height is not constrained. I even
provided diagrams showing the content spilling out of the bottom of the
left pane container and also the viewport (because I mentioned that I set
the height of the scrollable, i.e. overflow:auto, container to each the
bottom of the viewport).

I do understand these matters are complex and difficult to describe in
email. I don't fault you.  I am trying to figure out how to communicate
with more clarity in email.


>>> 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.

Sounds like what I need.  So the "block's height" is the height of
container that is being overflowed out of?

The problem remains of what to do with the existing browser behavior? (set
your overflow:auto to test)  The existing browser don't set the columns to
the block height, they let the columns take on the of the content inside
the container (as if I had set height:auto, but I didn't).

Received on Tuesday, 12 October 2010 20:41:04 UTC