W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [css3-multicol] 'column-fill' and column overflow

From: David Hyatt <hyatt@apple.com>
Date: Sun, 03 Mar 2013 12:06:26 -0600
Cc: www-style@w3.org
Message-id: <1579F4BC-9F59-432D-BA19-20F32B4F5742@apple.com>
To: "L. David Baron" <dbaron@dbaron.org>
On Mar 2, 2013, at 3:38 PM, L. David Baron <dbaron@dbaron.org> wrote:

> Second, it seems odd that the distinction it draws is between being
> *in* the overflow columns rather than whether the container *has*
> overflow columns.  By this, consider the example of a multi-column
> container with 2 non-overflow columns and a large unbreakable piece
> of content at the start of the third column.  It seems odd to lay
> this out as:
>  +---------------------------+
>  |+-----------+ +-----------+|+-----------+ +-----------+
>  ||text text  | |text text  |||+--------+ | |text text  |
>  ||text text  | |text text  ||||IMAGE   | | |           |
>  ||text text  | |text text  ||||        | | |           |
>  ||text text  | |text text  |||+--------+ | |           |
>  ||           | |           |||text text  | |           |
>  |+-----------+ +-----------+|+-----------+ +-----------+
>  +---------------------------+
> with balancing happening between the first two columns, but not
> happening in the overflow columns.  It makes more sense to me to
> disable the balancing in continuous context when overflow columns
> are *present*, and only use balancing in continuous contexts when
> there is excess height within the multicolumn element and no
> overflow columns.  That seems to me to be the main use case for
> balancing; having to do balancing in the other cases seems to me
> like extra implementation complexity and reduced performance without
> strong justification.

I think the spec needs to really spell out when and how balancing is supposed to occur, because right now I really have no idea when or how I'm supposed to balance columns. The current implementation of balancing in WebKit is pretty poor as a result, since the spec hasn't really provided enough information for me to really understand what I'm supposed to do. I have no idea how forced breaks affect balancing. I have no idea how overflow affects balancing. There is no balancing algorithm in the spec, so I don't know what the expectations are for balancing (is it 2-pass, is it n-pass, etc.).

My own intuition regarding balancing is that it is done per-column-row, so it seems like the spec should be talking in terms of column-rows. I would think that balancing would be done when:

(1) The height of the column-row is both unknown and not constrained by any enclosing pagination context, so you have to create equal height columns to try to determine the height of the column-row. This could include overflow columns, the column-row on the last printed page, etc.  I don't think you would want to special case overflow in this situation, since you would not even know you had overflow columns until you had done a layout with the balancing guess.

(2) There is excess height in the column-row. Even then I have questions… if the excess height is caused by a forced page break for example, but all the columns in the row had unforced breaks, do you balance the columns on that page?

I really think we need clear and precise rules for exactly when to balance, and I think the spec needs to actually provide an algorithm for balancing, even if it's just informative. Something on the level of


but explaining how to balance would be helpful.

Received on Sunday, 3 March 2013 18:06:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:23 UTC