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

Re: [css3-multicol] overflow and paging?

From: Shelby Moore <shelby@coolpage.com>
Date: Tue, 12 Oct 2010 02:13:46 -0400
Message-ID: <2f8eb79d96cb8bb84508872e3be04f1a.squirrel@sm.webmail.pair.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style@w3.org
> 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.

OFF TOPIC: afaik the browser will never overlow to the right by making
more columns than will fit into the width of the container element. So I
am wondering why you mentioned a need to turn that off, if it never
occurs? Thus I don't (yet) see the point of your second proposal.

ON TOPIC: Is the following that you mean by "paged" overflow? I ask
because you had previously mentioned flowing the overflow to another
element, which is not what I want. I simply want the content to paginated
within the container as if the container is the page height. Is that too
simple to do?

Afaics, the current rules are wrong, because for most uses it is wrong to
force reader to scroll (the scroll bar) to the end of something and back
to the top again, in order to read right-to-left.

When you have a vertically self-scrolling overflow container on the page
(i.e. overflow:auto or overflow:scroll), the columns should be paginated
within the scrolling container, such that the page height = the
container's clientHeight.

If you want to make it optional, we simply need a new setting, e.g.
column-overlow:paginate
Received on Tuesday, 12 October 2010 06:14:13 GMT

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