W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] overflow and paging?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 15 Oct 2010 09:38:13 -0700
Message-ID: <AANLkTi=t_2_vjMNxff_E2tXE1Uzg573+iToRLCZ1BOLR@mail.gmail.com>
To: shelby@coolpage.com
Cc: Andrew Fedoniouk <news@terrainformatica.com>, www-style@w3.org
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.

However, if you put overflow columns in the block direction rather
than the inline direction, then you do need a separate control.  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.

So, yeah, you really want auto height, but a constrained column
height.  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".

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.)

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'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.

Received on Friday, 15 October 2010 16:39:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC