773823 - [css3-multicol] Balancing across columns is disrupted by a non-breakable element

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Scott Johnson (:jwir3)]

If we encounter an element that we can't break, and has height >= our column height when balancing columns, we stop balancing currently. In the example URL, we have a column that has an image with height > our available height. There should be only 4 columns: three columns with text and one column with the specified image. However, because we don't balance properly after the image is encountered, the first column only gets 2 lines of text, resulting in an extra line left over at the end of the algorithm, which needs to be placed in a new, overflow column.

Comment 1

[Scott Johnson (:jwir3)]

Some observations -

This case:

XXXXXXXXXXXXXXXXX | ------Image------ | XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX | ----------------- | XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX | ----------------- | XXXXXXXXXXXXXXXXX
                  | ----------------- | 
                  | ----------------- | 
                    -----------------

is very similar to the following case:

XXXXXXXXXXXXXXXXX | XXXXXXXXXXXXXXXXX | ------Image------
XXXXXXXXXXXXXXXXX | XXXXXXXXXXXXXXXXX | -----------------
XXXXXXXXXXXXXXXXX | XXXXXXXXXXXXXXXXX | -----------------
                  |                   | -----------------
                  |                   | -----------------
                                        -----------------

The difference is, the latter case renders correctly in our current balancing code. It's only AFTER our balancing code encounters a non-breakable element that we see problems in balancing.

Thus, I thought we might be able to alleviate this issue, and preserve most of our code by moving a particular child to later in the child list of the column set frame, rebalancing, and then moving it back. 

We'll need two additional data members to ColumnBalanceData, one integer called 'mNumNonBreakingColumns', which tracks the number of non-breaking elements that exceed our maximum column height, and one list of integers called 'mNonBreakingPositions', which tracks the original positions of the non-breaking children, as this algorithm will reposition them temporarily.

1) Attempt to balance as normal.
2) If we have a column that exceeds our computed height, and columnCount < mBalanceColCount - mNumNonBreakingColumnns
  a) Add the current columnCount to a list (probably stored in ColumnBalanceData).
  b) Move the current child to the end of the child list.
  c) Increment mNumNonBreakingColumns.
  d) Restart balancing.
3) When balancing has finished (we have a feasible height that we're happy with).
  a) For X from 0 to mNumNonBreakingColumns
    i) Insert the column (mBalanceColCount) - (X + 1) back to its original column position, specified by mNonBreakingPositions[X].

This is pretty rough, but comments/guidance would be helpful.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Scott Johnson (:jwir3) from comment #0)
> If we encounter an element that we can't break, and has height >= our column
> height when balancing columns, we stop balancing currently. In the example
> URL, we have a column that has an image with height > our available height.
> There should be only 4 columns: three columns with text and one column with
> the specified image. However, because we don't balance properly after the
> image is encountered, the first column only gets 2 lines of text, resulting
> in an extra line left over at the end of the algorithm, which needs to be
> placed in a new, overflow column.

What rendering do you expect? We can't move any text to be before the image, that would be incorrect.

Comment 3

[Scott Johnson (:jwir3)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2)
> What rendering do you expect? We can't move any text to be before the image,
> that would be incorrect.

Maybe my expectations are incorrect. I originally thought that we could move text prior to the image, but now that you point this out, you're right, it's incorrect. 

However, I do think that we should be balancing the columns that come after the images. In the case I gave, we have overflow columns, which, as per the spec, are not affected by column-fill. However, if we look at the following example:

http://people.mozilla.org/~sjohnson/b764567/columnfill-nonbreak-img-4.html

I think that the last two columns should be balanced.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Scott Johnson (:jwir3) from comment #3)
> http://people.mozilla.org/~sjohnson/b764567/columnfill-nonbreak-img-4.html
> 
> I think that the last two columns should be balanced.

I guess so. That might be hard to implement though.

Comment 5

[Scott Johnson (:jwir3)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> (In reply to Scott Johnson (:jwir3) from comment #3)
> > http://people.mozilla.org/~sjohnson/b764567/columnfill-nonbreak-img-4.html
> > 
> > I think that the last two columns should be balanced.
> 
> I guess so. That might be hard to implement though.

I'm a bit confused. Isn't this what you're advocating to do in bug 764567, comment 3, where you say:

> Why are we reverting to auto just because one column overflowed?
> 
> It seems to me that if one column has a very tall element in it that we
> can't break, it still makes sense to balance as much as we can instead of
> reverting to auto.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, I hadn't thought through the issues when i wrote that comment.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think balancing the non-overflowing columns is probably the right thing to do, but it seems difficult.