[css-box-4] Applying `margin-trim` to fragmentation containers

[fantasai]

Pulling out a comment from https://github.com/w3c/csswg-drafts/issues/3314#issuecomment-439218520

We did also resolve to add a margin-trim property which operates on the container, and it seems reasonable to specify that if it is applied to a fragmentainer it applies to margins at breaks at the start/end of the fragmentainer.

@jensimmons and I discussed this, and we think margin-trim applied to a multi-column container should apply to margins at the top/bottom of each column box. We think this would be closer to expected behavior than applying it e.g. only to the top of the first column / bottom of the last column. Agenda+ to discuss.

[bfgeek]

Applying generally to fragmentation containers is somewhat troublesome. E.g. for grid we calculate the grid once, then fragment based on that. We can expand grid rows (in certain cases, e.g. when not fixed) due to fragmentation, but shrinking is complex (detecting how much to shrink is problematic) which at first glance would be required in this case.

Table has the exact same problem, and flex has similar issues.

Block layout is ok! And we already do this when we fragment across a margin: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13014

[frivoal]

Thought the properties work differently, in terms of use cases, this feels related to https://www.antenna.co.jp/AHF/help/en/ahf-ext.html#axf.margin-break, which is discussed in https://github.com/w3c/csswg-drafts/issues/3254

cc: @MurakamiShinyu

[css-meeting-bot]

The CSS Working Group just discussed [css-box-4] Applying `margin-trim` to fragmentation containers.

The full IRC log of that discussion

<fantasai> dholbert: it's observable wrt what fits in the column, and if the multicol box itself is auto-height
<florian> q+
<andreubotella> fantasai: Jen and I think it makes sense if an author applies margin-trim to a multicolumn container, that it should apply to both the top and bottom
<fantasai> of the column box
<andreubotella> bfgeek: For grid and flex I don't think it's a problem. For block layout, we have the same problem as before: start is fine, end is even more complex than text-box-trim
<andreubotella> When you're processing an element, you fundamentally don't know the end margin of it
<fantasai> andreubotella: for line-clamp: auto I'm keeping track of the bottom margins in order to subtract relevant sizes when computing block size
<fantasai> andreubotella: that's currently implemented in Blink, but only when you have line-clamp
<fantasai> andreubotella: idk if it could be useful for this
<astearns> ack florian
<andreubotella> florian: in terms of use cases, this is important to consider, because trimming the margins at the start of all columns is something authors may want
<fantasai> https://www.w3.org/TR/css-break-4/#break-margins
<andreubotella> ... this exists in AntennaHouse, which means there's demand for it
<andreubotella> fantasai: we have that spec'd on the ... property. If it says keep, you keep it regardless of margin-trim
<fantasai> s/.../margin-break/
<andreubotella> bfgeek: I'm oscillating between "it's actually easier" and "it's harder". I'd like to talk to Morten about it
<andreubotella> we could resolve that it only applies to block layout
<andreubotella> that might be something to make forward progress
<andreubotella> PROPOSED: margin-trim only applies to a multicolumn container by trimming block-level margins at the top and bottom of each column box
<andreubotella> florian: Is this only multicolumn? Pages printed side-by-side have the same demands
<andreubotella> fantasai: What are you setting it on then?
<andreubotella> florian: The root?
<andreubotella> fantasai: They're both kind of similar, I'd like to resolve on this one sooner than later
<andreubotella> bfgeek: I'll meet with Morten next week and chat with him abotu this
<andreubotella> astearns: If we have not come back to this by TPAC, I'll make sure it's on the agenda then
<iank_> ive got to drop now soryr.