Re: [css3-multicol] overflow and paging?

On 12 Oct 2010, at 08:13, Shelby Moore wrote:

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

If you restrict the height of an element, and there are too much  
content to fit into the columns you specify, the default behaviour is  
to create new overflow columns to the right of the existing columns.  
This happens in both WebKit and Gecko.

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

-- 
David Storey

Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG:  Mobile Web Best Practices / SVG Interest Group

Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dstorey@opera.com / Twitter:  
dstorey

Received on Tuesday, 12 October 2010 06:26:13 UTC