Re: [css3-multicol] overflow and paging?

> On Oct 14, 2010, at 11:33 AM, "Shelby Moore" <shelby@coolpage.com> wrote:
>
>> In this case, wouldn't it be much more predictable if multi-col
>> containers
>> always limit their column height to any blocking constraint of their
>> outer
>> containers, up to but not including the viewport or frame?
>
> No, because that is not how overflow and height normally interact.


Incorrect.

I am not proposing the the flowed content height be limited, but rather
only the "column row height".

Realize that the number of rows of columns will still be allowed to flow
in the block direction in compliance with the fact that the multi-col
element is "height:auto" (aka block unconstrained).

The only thing that my proposed "column-height:constrain" as the default
affects is the row height of the columns, not the actual height of the
overflow.

I realize that is very confusing if only expressed in words.  Again I
refer you to my diagram at following link, so that you can see that the
content height is not constrained (both cases in the diagram have nearly
same content height), rather only the row height of the columns, which
only affects the order of what is flowed into the columns. And that order
is critical as I explained, because the user can often not know visually
what the correct order should have been (but yet the error in order is
important):

http://lists.w3.org/Archives/Public/www-style/2010Oct/0256.html

It is a deeply psychological point.  Columns are special because they can
order large groups of things for which the viewer has no way of knowing
what the correct order should have been. Thus the order must always be
correct, we can't leave it to trial and error as we normally do with CSS.
Do you really think web developers read the specs?  And even they did, no
one is perfect.  With most CSS mistakes, you get a visual clue.  In this
column order thing, you don't in many cases.


> What
> you are essentially asking for here is that when the column count is more
> than one, that it automatically triggers a 'max-height:100%'.


Incorrect.

I am only saying that the "column row height" should be constrained to the
any outer block direction constraint.

[snip because irrelevant]

> The fact is, when you put a tall element (such as an auto height DIV with
> a lot of content and no max-height) into a shorter container, you have an
> overflow situation, and it would be very confusing if that weren't true
> just because there was more than one column.


And that won't change with my proposal. I am only proposing to fix the
error condition. Don't we like to fix typography errors here or not?


> What's really needed for you use case is a way to handle overflow
> differently, so that it is paged, or otherwise worked more like the
> constraints of a fixed page size.


That is an orthogonal issue which we already resolved in this thread.  Yes
we need to add Tad's proposed, "column-overflow:inline | block".  But that
has orthogonal issue to the error I am proposing to fix with
"column-height:constrain | auto", where 'constrain' is the default.


> The obvious place to handle that is with
> a new value for the 'overflow' property. This would be useful whether you
> put it on a container or on an actual multi-column element, or on elements
> that have nothing to do with multiple columns.


Good idea.  I am happier with adding "overflow: inline | block", than
"column-overflow: inline | block". I have wanted for a long time to be
able to enable scroll only on 1 axis.

> In theory, it could even
> have a way to set a page changing animation ('overflow: paged slide-up
> 1s), or a way to have a more normal scrollbar with the overflowed content
> coming from a different side as a continuously flow of pages ('overflow:
> auto from-bottom', though that'd be a bit weird if you had both horizontal
> and vertical overflow).


Sure we can get into neat things with overflow options.  I will let you
guys handle that process.  I was just here to report the two issues I did.


>> And then have
>> an explicit setting to turn that off, e.g. "column-height:auto".  So the
>> default would be "column-height:constrain".
>
> We already have ways to constrain height: min-height, max-height, and
> height. And the physical height of pages.

But the "column row height" is a different thing entirely.  I hope my
diagram link and explanation above makes that clear.

Thanks a lot for the reply, you helped illuminate the misunderstandings so
that I could clarify for the list.

Received on Friday, 15 October 2010 00:08:26 UTC