[css-multicol] Can overflow content influence column height?

[rachelandrew]

An issue raised in October 2013 on www-style:

An issue come up today in a discussion with a seasoned multicol
implementer: does overflow content influence column height?

Consider a multicol element with two columns, and column breaks after
each paragraph:

article { columns: 2; background: yellow }
p { break-after: column }

Then you pour three p elements into the article: two one-liners and then one long paragraph (say, 10 lines). What's the resulting height of the article? 1 or 10 lines (disregarding padding for a moment).

I can see two alternatives:

(1) the multicol element is made high enough to fit all columns. In this case, there will be three columns: two with one line each, and a third column -- outside the multicol element -- with 10 lines. The yellow box will be high enough to fit the third column, even if it shown outside the multicol element.

(2) the multicol element is made high enough to fit all columns that end up inside the box. So there will be two columns with one line of text each inside the multicol element, and then there will be 10 overflow columns outside.

I think I have a slight preference for (2).

Implementations vary, and it's hard to test as not all support explicit column breaks.

In comments 1, 2 on this issue @astearns and @tabatkins seem to agree on 2.

[tabatkins]

Yeah. If coming at this from nowhere, I'd probably answer (1), but the existing behavior of balancing and spanning leans me heavily towards (2), as Alan argued in the past.

[css-meeting-bot]

The Working Group just discussed Can overflow content influence column height?, and agreed to the following resolutions:

• RESOLVED: Go with option 1 in this sizing issue- overflow columns effect the multicol container's height

The full IRC log of that discussion

<dael> Topic: Can overflow content influence column height?
<dael> github: https://github.com//issues/1745
<dael> rachelandrew: This one...[reads]
<dael> rachelandrew: There's an example in the comment.
<dael> rachelandrew: What's the result 1 or 10 lines? Multicol is high enough to fit all so it's 3 columns with one column outside or it's made high enough to stay inside and there's 2 columns.
<dael> rachelandrew: Seemed to agree on second option, but I didn't know if anyone else had comments.
<dael> fantasai: Prefer 1
<dael> fantasai: Conceptually there's a row of column boxes and I'd like it high enough to contain all.
<dael> TabAtkins: astearns comment points out balancing only happens in the specified columns.
<dael> TabAtkins: I agree 1 is better overall but because balancing we should be consistent and ignore overflows.
<dael> dbaron: When are you in a balancing situation with overflow columns and no column break
<dael> TabAtkins: You have 2 1/2 columns with or data nad you have a column break you balance across the columns.
<fantasai> Dael, for previous issue here's the whiteboard https://lists.w3.org/Archives/Public/www-style/2018Apr/0009.html
<dael> astearns: It's easy with explicit breaks. not sure without. Maybe a monolythic column that doesn't fit?
<dael> fantasai: I think you have too much content to balance when there's overflow. So it gives up at that point.
<fantasai> s/I think/I think the reason balancing doesn't consider overflow columns is that/
<dael> florian: Monolithic thing and the thing before is 1.5 columns of content and then you have content after monolith and you balance before that?
<dael> fantasai: Balancing doesn't balance the coilumns that aren't there?
<dael> astearns: The ones not in the multicol element.
<dael> florian: So you get 2 columns of .75 width, then a monolith and then content after that that overflows?
<dael> fantasai: Need a test case
<dael> fantasai: What's a case that would trigger this?
<dael> fantasai: If you have a bunch of text and it breaks. You have 3 columns, you fill the first 2 and 10% of third and then a giant image that's overflowed. The three columns then rebalance. Does anyone impl that?
<dael> florian: [whiteboards] [there's a 1st column that's filled with text, a second column with a bit of text and a large image. It then goes into 2 columns of balanced text and then the image is in an overflow to the right.]
<dael> fantasai: I don' think anyone impl
<dael> florian: Do we agree spec says that?
<dael> TabAtkins: That's what astearns said and I'm believing him.
<dael> astearns: 4 years ago it did.
<dael> fantasai: [reads] [no effect in overflow columns]
<dael> fantasai: I think it should say no effect when there is overflow columns
<dael> Rossen: Test case?
<dael> fantasai: Trying to write one.
<dael> astearns: It's just that one setence afaict
<dael> florian: Performance wise it seems preferable to not do this.
<dael> florian: Design-wise...?
<dael> astearns: I think my reply is just the interpretation of that ambig sentence.
<dael> fremy: If my test case is right I don't think we do it.
<dael> fantasai: Mozilla does not rebalance.
<fremy> https://wptest.center/#/0gcmv9
<dael> [fantasai works with test case more]
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5904
<fremy> ^ my test case in case this is correct
<dael> fantasai: Chrome rebalances all of them. It does the overflow and the regular.
<dael> astearns: So not following spec differently.
<dael> Rossen: We're rebalancing as well.
<dael> florian: Is break-inside:avoid impl by everyone?
<dael> fantasai: If you didn't you wouldn't get everything
<dael> fantasai: That's why I sued page-break:inside
<dael> fremy: That's for page.
<fantasai> s/sued/used/
<dael> astearns: Back to the issue. People prefer taking into account the height of the overflow columns in determining height of multicol container.
<dael> astearns: I think I still find that weird when you have overflow:hidden and you can have unfilled columns
<dael> fantasai: But if you have overflow:scroll you want to scroll.
<dael> astearns: I don't mind option 1
<dael> florian: More sense to me.
<dael> rachelandrew: Yeah.
<dael> astearns: Resolve on option 1 or still working on test cases?
<dael> fremy: My test case shows edge is not rebalancing.
<dael> [fantasai goes to look at fremy test case]
<rego> this is using break-after: https://codepen.io/mrego/pen/GxLQJm
<dael> [arguing over test cases]
<dael> fremy: FF does not rebalance I think.
<rego> in Chromium the size of the multicol container is 2 lines, in WebKit it's 1 line (in my example ^)
<dael> fantasai: fremy in my test case if you remove the word columns.
<dael> fantasai: nevermind.
<dael> Rossen: Do we have enough to resolve? Should we come back later so people can play with test case?
<dael> fantasai: It's clear we're not doing that line in the spec
<rego> and in Edge my example has a bigger height
<dael> astearns: I think we can resolve on this issue and add a new issue for balancing in overflow columns.
<dael> Rossen: This is L1?
<dael> rachelandrew: Yeah.
<dael> Rossen: Okay
<dael> astearns: Prop: Go with option 1 in this sizing issue- overflow columns effect the multicol container's height
<dael> Rossen: Other opinions or objections?
<dael> Rossen: Overflow columns effect container height is the proposal
<dael> florian: support
<dael> rachelandrew: support as well
<dael> RESOLVED: Go with option 1 in this sizing issue- overflow columns effect the multicol container's height

[mrego]

BTW, this is an example for this issue: https://codepen.io/mrego/pen/GxLQJm

In WebKit and Chromium the mutilcol container has 1 line height. Like the overflow columns.

In Edge it has a bigger height, and the overflow columns also have that height.

It seems break-after: column; is not supperted on Firefox yet.