Re: [css3-multicol] overflow and paging?

> On Fri, Oct 15, 2010 at 2:37 AM, Shelby Moore <shelby@coolpage.com> wrote:
>> "column-height:constrain"
>> ==================================
>>
>> In addition to that improvement above, there is another issue I am
>> raising
>> in this thread.
>>
>> When the multi-column element is not constrained in the block direction
>> (i.e. height), but is contained with some element in its parent
>> hierarchy
>> which is constrained in the block direction, then a column layout
>> typography error occurs.  See the diagram here:
>>
>> http://lists.w3.org/Archives/Public/www-style/2010Oct/0256.html
>>
>> That error is not visually detectable in many cases, and thus it the
>> type
>> of error that could (probably will) proliferate if we don't make it
>> harder
>> to do wrong. This is why I proposed adding "column-height:constrain" and
>> "column-height:auto", with "column-height:constrain" as the default.  In
>> the "column-height:constrain", then the blocking constraint of any outer
>> container will control the "column row height" and thus prevent the
>> error
>> from occurring.  Note this is the row height of the columns, not the
>> height of the content which contains the columns.  The content height
>> will
>> not be controlled and will still flow freely when the multi-column
>> element
>> is not itself constrained in the block direction. It is a convoluted
>> thing
>> to understand, but with that proposed default then it will simply work
>> correctly.  See the following archive post for the more detailed
>> explanation:
>>
>> http://lists.w3.org/Archives/Public/www-style/2010Oct/0271.html
>
> I've come to agree with you that direct control over the column height
> would be useful.
>
> In the current column overflow model, the column height is always just
> the content height.  There's no particular use-case for introducing a
> separate control for the height.


Understood on the current conceptual model.

Let me qualify that the outer container can clip those column (= content)
heights, causing scrolling tsuris (which is also an accessibility
quagmire[1]) and sort order randomization as previously described. In any
case, your proposal below to generalize the model, will also solve this
outer container clip issue too.

[1] http://lists.w3.org/Archives/Public/www-style/2010Oct/0285.html



> However, if you put overflow columns in the block direction rather
> than the inline direction, then you do need a separate control.


Agreed.  Which also means you deal with the fact that they are currently
inline with respect to the outer container clip, and thus deal with that
error too.

I like the way you have put thought into this and generalized the model,
which also solves the error (aka hole) in the current model.


>  The
> alternative is just setting the height of the element directly, in
> which case the overflow columns *actually* overflow the box.  This is
> unacceptable if you have a background, border, box-shadow, or similar
> on the box, because then the extra columns will be outside the
> boundary defined by those.


Good points.  Not only that, but if you make the column-height = height
(bad conflation!), and don't set it to 100vh by default, then the same
outer clip error creeps back in. And if you do set height to 100vh by
default on multi-column elements, then it doesn't make any sense
(conflation is causing gridlock).


> So, yeah, you really want auto height, but a constrained column
> height.


Agreed.  There is no other way.


>  I don't think we need a new keyword - the behavior we want is
> already specifiable with the vh unit, which represent 1% of the
> viewport's height.  So you could have something like
> "column-max-height: 100vh" as the default value.  It would otherwise
> accept any length, with a value of 'auto' meaning "no maximum height".


Very nice generalization. Thank you for spending the effort.


> Similarly, for usability purposes you really want a minimum column
> height.  Robert O'Callahan's blog is occasionally almost unreadable
> because he uses multicol; whenever his post is short it flows two or
> three lines into each column.  (It's really confusing when it's short
> enough to do only a single line per column - it looks like there are
> just random large spaces breaking up the sentence, where the column
> gaps appear.)


Yes that is great, and one can use em units I assume that will apply to
the em of the line height content that is in the column, not em of
multi-column element itself?


> This is more complex than a max height, as it would need to affect
> whether or not column-width and column-count are honored.


I think this ties in with my proposal for flexible column-width:

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

I have no current thoughts about column-count case.


>  I'd have to
> sit down for a bit and work out exactly what the interaction between
> the three properties would be.  Alternately, this could possibly just
> break column balancing instead, but I'm not sure how great that is.
>
> Overall, these are just putting back some constraints that come for
> free in print layout, but which we lost moving to the web's infinite
> canvas.  In print, overflow columns always work correctly, columns
> never get too tall, and column heights at the end of chapters are
> looked at by humans to ensure they look nice.


Feels great when things generalize out.

Thanks again for looking at this issue.

Received on Friday, 15 October 2010 17:06:29 UTC