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

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Thu, 4 Apr 2013 21:50:57 +0200
Message-ID: <20829.55713.605650.611375@gargle.gargle.HOWL>
To: David Hyatt <hyatt@apple.com>, "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
David Baron 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.

In a previous discussion, we concluded that we wanted to honor
'column-fill' for all content, not just the last page.


Overflow columns are similar to pagination, and it therefore seems
reasonable to apply 'column-fill' to overflow columns as well. 

So, I'm tempted to remove this line from the spec:

  In continuous media, this property does not have any effect in overflow columns

That's not quite what you propose, but is it something you would agree

David Hyatt wrote:

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

True, the spec is not very specific. It declares a goal for balanced
columns ("UAs should minimize the variation in column length") but
also says that other constraints should be honored (like 'widows' and

My resident implementer tells me that trying to express anything
beyond this, either in prose or in a pseudo-algorithm, will quickly
become very complex. I'm hesitant to add complexities or new
requirements to the spec at this stage.

Note, however, that this text has been added to the editor's draft
after discussions with Anton Prowse:

  There are two strategies for filling columns: columns can either be
  balanced, or not. If columns are balanced, user agents should try
  to fill all columns in a row so that the columns appear to have the
  same amount of content, while also trying to minimize the overflow
  content. If columns are not balanced, they are filled sequentially;
  some columns may end up partially filled, or with no content at
  all. In any case, user agents must honor forced page breaks and
  should try to honor ‘widows’, ‘orphans’ and other properties that
  may affect column lengths.


Perhaps it addresses some of your concerns?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Thursday, 4 April 2013 19:51:41 UTC

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