Re: [css3-multicol] overflow and paging?

> On Sun, Oct 10, 2010 at 9:30 PM, Shelby Moore <shelby@coolpage.com> wrote:
>> Seems to that when a container element on the page has overflow that
>> scrolls vertically (e.g. <div style='overflow:auto'>), then any
>> contained
>> columns should be formatted as if they are paged media with a height
>> equal
>> to the clientHeight of container.
>>
>> If I am viewing long multi-column content inside of a scrolling
>> container,
>> I don't want to have to scroll that container all the way from the
>> bottom
>> to top to read from one column to the next. Imagine that you don't flip
>> to
>> the last page of a newspaper back to first page, just to read from
>> bottom
>> of one column to the top of the next column.
>>
>> Also, I don't want to see the end-most content before I am forced scroll
>> to see the content in the middle.
>>
>> I think this is a major oversight in the current specification.  I hope
>> you will fix it.  Sorry to be frank, but as it is now, it makes my
>> current
>> website look sloppy and wrong.
>>
>> Realize I am not referring to paged media, where the entire browser
>> window
>> is being broken into pages.  I am referring to an element within the
>> page
>> which has its own vertical scroll page, which would include <iframe>.
>>
>> I suppose there are cases where the intention is for the columns to not
>> paginate on clientHeight of the vertically scrollable container, and
>> thus
>> I suggest you need to declare a new style setting, such as
>> paginate-scrollable-contrainer, which defaults to inherit, where the
>> document defaults to the whether the media type is paged.
>
> I'm pretty sure I speak for the group when I say that we recognize
> that having a multicol element be higher than the viewport is bad.
> Luckily, this can be fixed with a unit in CSS3 Values & Units, once
> browsers support it.  Just set "max-height: 90vh;" or similar to
> prevent the element from too tall.

Thank you for reading and replying.

If I am understanding you correctly, I think you misunderstood my point?

The problem I described is where I have set the container element to be
smaller than the viewport height (using JavaScript until CSS Units are
available).

The problem is that the multi-column content in that container is *MUCH*
taller than the container, so I have to scroll the container from bottom
to top as I read right to next column. The problem is not the height of
the container, but rather that the multi-column layout is not paginating
*WITHIN* the container to the height of the container.

This also causes the end of the content to be in the first "page", and the
middle of the content to not be on the first "page", where "page" means
the (clientHeight) height of the container element.

Does that clarify the problem, or do I need to clarify further?


> Personally, if you're using multicol on your blog or similar, I

Actually it is social network I am launching in Asia. Intending to be a
very high traffic site. I've did a million user site in 2001
(coolpage.com)

> recommend having it default to a single-column presentation, then in
> javascript measure the screen height, set an appropriate max-height,
> and turn on multicol.

I am setting the column-width to expected width of the user profiles that
appear in the left pane (which is sized to the height of the window), so
that when they are clicked the profile details appear in the right pane. 
The pane border is movable, so the user can adjust how many columns they
see.  The problem is that sort order is all messed up, because of this
problem I have described.  The things that shouldn't be at the top are,
and things that should be there, are not.

I created one of the world's first WYSIWYG multi-column word processors
for PC (WordUp for Atari ST in 1986). I contributed to the column
specification for CSS2.

Hope we can get this fixed in the specification? Or am I missing something?

> That ensures that your viewers have a decent
> experience no matter what, given currently available technologies.
>
> ~TJ

Received on Monday, 11 October 2010 17:03:57 UTC