Re: [css3-multicol] overflow and paging?

On Mon, Oct 11, 2010 at 3:09 PM, Shelby Moore <shelby@coolpage.com> wrote:
>> On Mon, Oct 11, 2010 at 10:55 AM, Shelby Moore <shelby@coolpage.com>
>> wrote:
>>> I am reasonably sure you still don't understand my point. Let me draw
>>> from
>>> diagrams to see if you can clarify if I am misunderstanding you, or vice
>>> versa?  Apologies I should have drawn this in first post, as I guess
>>> this
>>> sort of thing isn't easy to visualize from written description.
>>>
>>> I am not using an <iframe>, but rather a <div style='overflow:auto;
>>> column-width:xxx'> as I wrote in my opening post for this thread.  I
>>> size
>>> this <div>(1) such that it is height of the viewport:
>>>
>>> -------------
>>> |           |
>>> -------------
>>> |   |       |
>>> | 1 |   2   |
>>> |   |       |
>>> -------------
>>>
>>> Then I fill that <div> with inline content and I set the column-width on
>>> the <div>, so then I have multiple columns displayed within that
>>> pane(1).
>>>
>>> The problem is that that I expect the columns in pane(1) to be paginated
>>> to the height of pane(1), so there will be page breaks __WITHIN__
>>> pane(1).
>>> There are no page breaks for the viewport, because the panes(1) and (2)
>>> never are taller than the viewport.  I have no way to make the inline
>>> content less tall, because the border between pane(1) and pane(2), is
>>> draggable by the user.
>>>
>>> In other words, I expect the following in pane(1) where my inline
>>> content
>>> is in alphabetical order:
>>>
>>> -------------
>>> |           |
>>> -------------
>>> |A D|       |
>>> |B E|   2   |
>>> |C F|       |
>>> -------------
>>>  G J
>>>  H K
>>>  I L
>>>
>>>  M P
>>>  N Q
>>>  O R
>>>
>>> But instead now I erroneously see:
>>>
>>> -------------
>>> |           |
>>> -------------
>>> |A J|       |
>>> |B K|   2   |
>>> |C L|       |
>>> -------------
>>>  D M
>>>  E N
>>>  F O
>>>  G P
>>>  H Q
>>>  I R
>>
>> Ah, now I see what you're saying.
>>
>> Okay, yes, this sort of thing has been brought up before, and will
>> likely be solved in a manner similar to what you're suggested - a
>> "paged" overflow method that flows excess content into another pane
>> which is accessible somehow.
>
>
> I did not suggest that.  There is no need to put the overflowed content
> into another pane, because my pane has scrolling (overflow:auto).  I can
> see all the content by scrolling, that is not the problem.
>
> The problem I want solved is much simpler, fundamental, and thus I expect
> more prevalent.
>
> The problem is the content is in the wrong order.  The columns should be
> formatted as if there is a page size _______WITHIN________ the pane equal
> to the height of the pane.  Please look again at my diagrams above and see
> that I want the order of the content to be correct.

No, I understood you correctly this time.  Given the current rules,
the content is *not* out of order; it correctly flows down to the
bottom of the element, then starts again at the top of the next
column.  There are a few ways to fix this - one way is to invoke a
"paged" overflow, as I stated in my previous email.  Another is to
provide a switch to multicol telling it that if you have more columns
than will fit, to overflow them underneath the existing content,
rather than to the right.  Is this second one more to your liking?  We
discussed this in our most recent face-to-face meeting, but didn't
produce anything from it.  I personally support such a mode switch,
though.

~TJ

Received on Monday, 11 October 2010 23:05:58 UTC