Bug 67232 – Padding can be split from line boxes across column boundaries

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Layout and Rendering

[Alan Stearns]

Created attachment 105699 [details]
Test file

It appears that column breaking decisions are only considering line boxes, and not the associated padding. This can result in a line's padding getting displayed in a different column than the line itself. Column (and Region) breaks should not slice apart padding.

[Dave Hyatt]

Yeah this is a problem I have totally punted on, since it's a very undefined space and I wasn't sure how far to take it.

A good general rule I think would be to prevent border/padding from ever being by themselves in a column with no associated child content also in the column.

However note that this could lead to some very complicated rewinding, since we'd essentially have to run block layout again in order to correct the initial placement.

I think this is fine though. It's algorithmically similar to what happens when you guess incorrectly and a collapsed descendant margin propagates up to you and forces you to re-evaluate your current position and lay out again.

However, we put in a lot of trickery to avoid O(n^2) explosions with this collapsed margin issue, and we'll probably have to do the same thing with pagination. We mainly avoided it by having the estimate use the collapsed margin from the previous layout attempt.

I think we can maybe do something similar with pagination, but I'd have to think about it.

[Alan Stearns]

There's also an issue with floats and columns, I think. If I have an image floated in a multicol element, it can get sliced across multiple column boundaries. My expectation (for images or floats with a single box, at least - I'm not entirely sure about floats with multiple line boxes) is that if a float will not fully fit in the remaining column height it should get pushed to the next column. Should the float issue be a separate bug, or should this bug be modified to encompass both floats and padding?

[Dave Hyatt]

Remember that entire pages are built using floats to hold the sections. For example floating main page bodies, floating sidebars, floating columns, etc. It's too simplistic to state that you can't ever paginate floats. People already abuse them to build entire page layouts, so you have to be able to split them.

[Dave Hyatt]

" If I have an image floated in a multicol element, it can get sliced across multiple column boundaries."

Do you have a test case? That isn't supposed to happen right now, since images are replaced elements and therefore unsplittable.

[Dave Hyatt]

For floats, we probably just need a heuristic that tries to keep the entire float together if it's "small enough"... where "small enough" may just mean < page height.

[Alan Stearns]

Looking at my test file a bit more closely, it appears that an image only splits if the column height is too short to fit the image height. That makes more sense to me, as there isn't an available place to fit the entire image so we give up and slice it apart. If the next column is tall enough, it does get pushed there.

[Dave Hyatt]

(In reply to comment #6)
> Looking at my test file a bit more closely, it appears that an image only splits if the column height is too short to fit the image height. That makes more sense to me, as there isn't an available place to fit the entire image so we give up and slice it apart. If the next column is tall enough, it does get pushed there.

Yeah, that's the intended behavior. For floats we may want to have similar behavior, i.e., be willing to paginate it if it can't fit (and then do good slicing), but try to keep it together otherwise.

Note that moving a float can have severe consequences, since when a float moves, the line it originated on moves with it. This is an important heuristic we have to keep working for iBooks.

[Alan Stearns]

"when a float moves, the line it originated on moves with it"

Is this heuristic limited to moving floats in column/page/regions? I'd put together a test file for https://bugs.webkit.org/show_bug.cgi?id=66198 where my expectation was that text following a float should always be laid out at or lower than the top edge of the float, but Alex showed me instances where text surrounding a float can be laid out above the float placement.

If there's a line with an image floated left at the bottom of a column where the content is ordered "before<float>after" and the line width fits, but the float height is too tall for the remainder of the column, what should move to the next column?

options (column 1 | column 2):
1. before         | <float>after
2. beforeafter  | <float>
3.                    | <float>beforeafter

[Ahmad Saleem]

With unprefixed '-webkit-column-count', all browsers (Safari 17, Chrome Canary 119 and Firefox Nightly 120) render this same:

https://jsfiddle.net/8n3t9xph/show

Do we need to do anything else?

[Karl Dubost]

Thanks Ahmad