[css-multicol] Multi-col, spanner margin collapsing, and formatting contexts

[frivoal]

Example 25 in multicol contains the following sentence:

The margins between the two spanners collapse with each other.

This seems reasonable, and I believe we discussed this and resolved in favor of it years ago, but I do not think it is fully supported by normative text. It is not contradicted by normative text either, but given that the multicol container is not a normal block formatting context, the behavior does not just fall out, and needs to be specified.

Arguably, it may fall out of this sentence, in section 2:

A multi-column container establishes a new block formatting context, as per CSS 2.1 section 9.4.1.

but that sentence itself seems strange to me, since a BFC wouldn't know what to do with column boxes, spanners, and the like. The content of the multicol goes into a BFC, but that it doesn't seem to me that the BFC is the multicol container itself. Shouldn't we rather say that:

1. columns establish a BFC.
   By the way, I am not sure if that should be a single column box establishing a single BFC, with each column being a fragment of that single box, or if each column is by itself a box which establishes a BFC. The former sounds more intuitive to me, the later seems a more similar to how we describe line boxes.
2. multicol containers establishes a multicol formatting context, whose formatting model deals with placing columns, spanners, column rules, placing overflowing columns to the right and so on
3. Within that multicol formatting context, the margins of adjacent spanners collapse with eachother, according to the same rules as in CSS2.1, explicitly invoked to work in this FC that isn't a BFC.

Alternatively:

1. idem
2. multicol containers establishes a BFC which contains column-row boxes and spanner boxes. Between these, margin collapsing works normally, since we're in a BFC.
3. column-row boxes establish a multicol formatting context, whose formatting model deals with placing columns, column rules, placing overflowing columns to the right and so on.

Finally, we also probably need:

4. review and maybe clarify / redefine "adjoining margin" in that context, to make sure it is concerned with siblings in the box tree (where spanners are siblings), and not siblings in the element tree (where they may not be). I think this is already fine, but CSS21 is not particularly careful when talking about elements and boxes, so this is worth auditing.

[css-meeting-bot]

The Working Group just discussed multicol, and agreed to the following:

• RESOLVED: Column boxes are BFCs
• RESOLVED: Second solution in the issue (spanners are BFCs that collapse margins).

The full IRC log of that discussion

<TabAtkins> Topic: multicol
<astearns> github: https://github.com//issues/2582
<TabAtkins> florian: I don't remember exactly how i found this problem, but;...
<TabAtkins> florian: In example 25 of multicol, sentence says the amrgin between adjacent spanners collapses together.
<TabAtkins> florian: I think everyone agrees with this, but it's onlys tated in an example
<TabAtkins> florian: We *could* say that it's already explained by "multicol is a bfc", but that doesn't explain why things have columns, so...
<astearns> example 25 in https://drafts.csswg.org/css-multicol-1/#column-span
<TabAtkins> florian: [reads out from issue]
<TabAtkins> iank_: Why do you want the margins to collapse together?
<TabAtkins> florian: NOt sure I do, spec just says it and implies it's a consequence already.
<TabAtkins> florian: Impls already do that
<TabAtkins> Rossen: This is an issue Håkon and I went back and forth with
<TabAtkins> Rossen: He argued it shoudl behave as much as possible as block layout when you have a single column
<TabAtkins> Rossen: I still disagree and think they shoudln't collapse
<TabAtkins> astearns: [draws example with some spanners next to each other]
<TabAtkins> florian: Right now you can only span 1 or span all, so not possible
<TabAtkins> dbaron: I think I filed an issue with this earlier, but...
<TabAtkins> dbaron: If the columsn themselves don't form BFCs, then floats don't float to the column
<TabAtkins> florian: They definitely do
<TabAtkins> dbaron: I don't see that in the spec.
<TabAtkins> RESOLVED: Column boxes are BFCs
<TabAtkins> florian: So either the multicol is a "multicol formatting context" that knows how to place columns and spanners, or we have some concept of an anoymous box that wraps a column row...
<TabAtkins> fantasai: I think that's a distraction, let's focus
<TabAtkins> astearns: So you propose we add text that column spanners collapse margins between each other as if they were in block layout
<TabAtkins> astearns: Objections?
<TabAtkins> Rossen: As long as it's only between spanners
<TabAtkins> Rossen: Are spanners BFCs?
<TabAtkins> fantasai: Yes
<TabAtkins> Rossen: So let's collapse margins!
<TabAtkins> rachelan_: We do that anyway to supprot spanners.
<TabAtkins> fantasai: Let's do a limited version of this. There's a box around the column row. That box and the column spanners are laid out as if they were block-lever siblings in a block container.
<dbaron> Florian mentioned somewhere in there that the definition of adjacency for column-span boxes isn't clear.
<TabAtkins> florian: Yeah, either that, multicol is a BFC laying out the row boxes and spanners, or there's no row boxes and multicol just magically knows how to position things.
<TabAtkins> florian: This might make it more difficult to introduce not-all spanners.
<TabAtkins> dbaron: Already hard.
<TabAtkins> dbaron: Does anyone remember whether poistion:relative on an ancestor of the column-span box that is a descendant of the multicol moves the spanner?
<TabAtkins> dbaron: That might affect whether you have wrapper boxes around the spanners.
<TabAtkins> florian: And if we just want to reuse the margin-collapse def from 2.1, we may need to revisit the notion of adjacent.
<fantasai> fantasai: We do layout on the box tree, not the element tree.
<TabAtkins> TabAtkins: adjacency is box-tree, not element tree
<TabAtkins> dbaron: The rules for whether an empty column row is generated might need to be made more specific, to give us good results for adjacency.
<TabAtkins> dbaron: Like if there was an empty block between the two spanners, does that create a column row that breaks adjacency?
<TabAtkins> fantasai and iank_: yes
<TabAtkins> dbaron: Okay, needs to be made clear.
<TabAtkins> florian: Example - piece of text with two em elements following each other. Both have a border. Both contain a div. The div is column-span:all. There is a border between the two divs, but they're taken out-of-flow. Are the spanners adjacent?
<TabAtkins> fantasai: No, the em splits into two boxes around the div, so there are boxes between the divs.
<TabAtkins> dbaron: So the end of an inline causes the creation of a line box, you're asserting?
<TabAtkins> dbaron: Maybe if it has a border...
<TabAtkins> fantasai: We discussed this earlier, but it matches block-in-inline splits.
<TabAtkins> florian: I don't want to deep-dive this, I suggest we keep to the two issues
<TabAtkins> dbaron: spanners margin collapsing still needs things defined...
<TabAtkins> florian: We should just resolve on the collapsing in general.
<TabAtkins> dbaron: We might have someone reviving our column-span impl sometime this year, so...
<TabAtkins> astearns: So are you saying we just add a statement that adjacent spanners collapse their margins?
<TabAtkins> florian: For now dependon 2.1's definition of adjacent, and open an issue to track whether it's sufficient or not.
<TabAtkins> [discussion about whether column rows should have boxes in the layout model, or not]
<TabAtkins> florian: I think that option is easier now. I wonder if it makes life harder when we do non-all spanners.
<TabAtkins> fantasai: I don't think so.
<TabAtkins> fantasai: In impl we won't actually create the boxes
<TabAtkins> dbaron: In our impl we do...
<TabAtkins> fantasai: Great, even better.
<TabAtkins> florian: So that means we're taking the original issue that starts with "alternatively..."
<TabAtkins> TabAtkins: So back to original issue?
<TabAtkins> florian: Original issue is that it seems impls say that spanner margins collapse, but spec doesn't say how. So this will solve that.
<TabAtkins> astearns: So "alternatively..." with extra details, like spanner boxes are bfcs...
<dbaron> block-within-inline behavior is that it's a function of whether there's a border: toggle "xborder" to "border" in
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Aspan%20%7B%20xborder%3A%20thin%20solid%20fuchsia%3B%20%7D%0Aem%20%7B%20display%3A%20block%3B%20border%3A%20medium%20solid%20blue%3B%20padding%3A%203px%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cspan%3Ea%3Cem%3EB%3C%2Fem%3E%3C%2Fspan%3E%3Cspan%3E%3Cem%3EC%3C%2Fem%3E%3C%2Fspan%
<dbaron> 3E
<TabAtkins> florian: I think we already have that one
<TabAtkins> astearns: So proposed resolution is second solution in the issue, in order to define spanner margin collapsing.
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Second solution in the issue (spanners are BFCs that collapse margins).
<TabAtkins> florian: I'll figure out with Rachel who does these edits.

[mstensho]

1. I'm not quite sure what having a column box establish a new BFC entails. Is it just about margin collapsing (and NOT about capturing floats or anything like that?)

2. If we want column boxes to be BFCs, shouldn't that also apply to all other kinds of fragmentainers as well, such as page boxes?