[css-multicol] Multi-col, spanner margin collapsing, and formatting contexts #2582
Example 25 in multicol contains the following sentence:
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:
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:
Finally, we also probably need:
The Working Group just discussed
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
<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.