- From: Shelby Moore <shelby@coolpage.com>
- Date: Mon, 11 Oct 2010 18:09:10 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org
> 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. My HTML code for the above hypothetical example looks like this: <div style='overflow:auto; column-width:Xem'> A B C D E F G H I J K L M N O P Q R </div> where 'X' is the width of one lettered unit. The problem is the columns are computed as if the page height is the height of the content. Whereas, what I want is that the columns will be computed with page height = clientHeight of the container <div>. > > Nothing's been written up quite yet for it, but I have it on my list > of things to look at in the next year, and I think a few others in the > group are interested in pursuing something in this vein as well. > > ~TJ > > >
Received on Monday, 11 October 2010 22:09:38 UTC