Repository navigation
[css-break] what happens to block margins that aren't between block-level boxes? #3073
Description
There's a section of the spec that defines what happens to block margins that are between block level boxes:
When an unforced break occurs between block-level boxes, any margins adjoining the break truncate to the remaining fragmentainer extent before the break, and are truncated to zero after the break. When a forced break occurs there, adjoining margins before the break are truncated, but margins after the break are preserved. Cloned margins are always truncated to zero on block-level margins.
But what about margins that aren't between block level boxes, such as a margin-block-start of the first child of a block formatting context (BFC), or a margin-block-end of the last child of a BFC?
Also see bug 1487927 about how this relates to column-balancing inside of a multicol... in interesting ways.
Activity
fantasai commentedon Sep 11, 2018
Note that you're only allowed to break there if there's a gap: https://www.w3.org/TR/css-break-3/#possible-breaks
fantasai commentedon Sep 11, 2018
Wrt sibling boxes, I think the multicol balancing case wasn't really thought through on this point... Probably the margin should be truncated to zero both before and after an unforced break. I'm uncertain what should happen with a forced break though... Probably the margin should count as content on the earlier fragmentainer for the purpose of balancing, but should be allowed to truncate if the fragmentainer height is too short to include the margin.
fantasai commentedon Oct 16, 2018
Proposal: treat these margins exactly like margins between siblings, i.e. margins before/after an unforced break are truncated to zero, margins after a forced break are preserved, and margins before a forced break are truncated.
@dbaron Does that make sense to you?
fantasai commentedon Oct 16, 2018
(@dauwhe says this makes sense to him, fwiw.)
dbaron commentedon Oct 16, 2018
It's not entirely clear to me what will happen in all the balancing cases; it might produce some surprising results. I guess truncation is at least well-defined in that moving content from one column to another will not cause the column losing content to grow or cause the column gaining content to shrink... at least as long as there aren't negative margins.
(I think the author of this testcase wasn't expecting any truncation, though, and was expecting margins to continue across multiple columns. I guess my original concern wasn't really a fundamental problem, but rather the violation of expectations.)
rachelandrew commentedon Oct 17, 2018
I think web authors probably won't expect truncation, however I think @fantasai's proposal will give the most pleasing results ultimately, and if the behaviour is well defined and can be explained (and is consistent cross-browser) then I think it works.
fantasai commentedon Oct 17, 2018
@dbaron Wrt the author of the testcase not expecting truncation... truncation is what currently happens if you break between siblings, so I think it would be more surprising if it didn't happen after the last child?
css-meeting-bot commentedon Nov 8, 2018
The CSS Working Group just discussed
what happens to block margins that aren't between block-level boxes?, and agreed to the following:RESOLVED: define that margin collapsing between first or last child behaves same as between sibling childrenRESOLVED: republish CR of Break L3 with this changeThe full IRC log of that discussion
<dael> Topic: what happens to block margins that aren't between block-level boxes?<dael> github: https://github.com//issues/3073
<dael> fantasai: This was the one issue open on fragmentation. dbaron suggested we can resolve
<dael> fantasai: What happens to margins...we have def when breaking between siblings, but not if you break before the first sibling or after the last.
<dael> fantasai: Typically you don't break there, you break before or after parent. You're only allowed to break there if there's a gap. If there's just extra space after layout you can break
<dael> fantasai: Proposed is do same as break at siblings. Truncate margins if forced, don't if unforced.
<dael> fantasai: Where that shows up is if you are in a multicol and you hae a much of stuff that breaks. You can tell if you truncated margin b/c height of multicol will be different if margin is there
<dael> Rossen_: Behavior sounds reasonable. This is what dbaron is proposing.
<dael> Rossen_: Other opinions?
<dbaron> yeah, sounds good to me... though not sure that it's what I was proposing
<dael> fantasai: He jsut wanted a definition. not sure if he wanted a specific one
<dael> dbaron: I don't think I was proposing something. sgtm
<dael> Rossen_: Objections to define that margin collapsing between first or last child behaves same as between sibling children ?
<dael> RESOLVED: define that margin collapsing between first or last child behaves same as between sibling children
<dael> fantasai: That's in L4, I'll edit into L3 then republish with that
<dael> Rossen_: Yes
<dael> florian: L3 is CR
<dael> fantasai: We resolved to publish already. There's just this one issue made sense to close it
<dael> Rossen_: Obj to republish CR of Break L3 with this change?
<dael> RESOLVED: republish CR of Break L3 with this change
mstensho commentedon Nov 8, 2018
cc me
[css-break-3] Clarify that margins adjoining Class C breaks are also …
fantasai commentedon Nov 14, 2018
Edits committed. @mstensho / @dbaron can I get a review? :) I'll submit for republication once you sign off on the edits.
mstensho commentedon Nov 15, 2018
@fantasai Looking good!