Re: [css3-multicol] overflow and paging?

> On Thu, Oct 14, 2010 at 10:54 AM, Shelby Moore <shelby@coolpage.com>
> wrote:
>> Thus isn't the spec is wrong then? Should it ever allow the column
>> height
>> to be greater than constrained height of any outer container, because
>> afaics the result is typographically erroneous. Note I am not referring
>> to
>> the non-paging media viewport container (including <iframe> and
>> <frame>).
>> Can anyone think of a valid need for that?
>
> Simplicity and predictability, mainly.  We could make CSS attempt to
> be smarter about how it reacts to ancestor heights, but that would
> make it harder to predict how it works.  It's fairly simple to fix the
> issue manually with a few "height:100%" rules scattered around.

I am usually the one to argue for orthogonality, so I agree with you on
that principle.

But the trade-off is that CSS is used by naive developers (like me
sometimes, hehe), who even after we add the "column-overflow:block"
option, are going to forget to put the "height:100%" and are going to
probably not even notice or care that the columns are too tall for the
container. I didn't notice that because of this, effectively the sort
order of the user profiles which is the flowed multi-col content (see
prior diagrams) was wrong until after weeks of working with my site every
day. It is deceptive thing that people won't really notice, the usability
error will accumulate somewhat silently.

Thus usability of the www could suffer. There is the amatuer programmer
requirement I think on CSS?

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? And then have
an explicit setting to turn that off, e.g. "column-height:auto".  So the
default would be "column-height:constrain".

Any opinion?

>> Thus in any case, none of the above removes the need for the
>> "column-overflow:inline|block", because if I constrain then the spec
>> currently always overflows inline (but I need block direction), and the
>> above code as a work around does not properly limit the column height.
>> The
>> columns are overflowed (clipped with a vertical scroll bar) in the outer
>> box but the column height is not restricted to height of the outer box.
>> Thus a result that is an "abomination" of column typography, as
>> explained
>> in my prior diagrams :D
>
> Correct; we still need a way to force overflow columns to be generated
> in the block direction instead.

Thanks. I will have long columns (incorrect sort order) in the meantime.

Received on Thursday, 14 October 2010 18:33:59 UTC