- From: David Hyatt <hyatt@apple.com>
- Date: Sun, 03 Mar 2013 12:06:26 -0600
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style@w3.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 http://dev.w3.org/csswg/css3-regions/#regions-visual-formatting-examples but explaining how to balance would be helpful. dave (hyatt@apple.com)
Received on Sunday, 3 March 2013 18:06:47 UTC