[css-break-4] Should margin-break apply to elements or fragmentation containers?

[bernhardf-ro]

In PDFreactor we have a property that works pretty much identically to margin-break (with a more convoluted name):
https://www.pdfreactor.com/product/doc_html/index.html#css-property-ro-truncate-margin-after-break
https://drafts.csswg.org/css-break-4/#break-margins

There is, however, one major difference: Our property applies to the fragmentation containers.

Our reasons for this were:

• It avoids lists of selectors or universal selectors. .columcontainer instead of .columcontainer h1, .columcontainer h2, .columcontainer p or .columcontainer * and @page instead of html, body, h1, h2, p or *
• It reduces complexity for both the implementers and authors. Nested break-adjoining elements with varying margin and margin-break values may result in hard-to-predict results, especially when the interaction with margin collapsing (e.g. in which order they are applied) is not obvious.

Of course, I understand that the finer granularity of the per-element approach may solve some complex cases, but, to be honest, I haven't been able to come up with any.

While we will, of course, implement the specification when it is mature, I would like to know your opinions on these two approaches.

[frivoal]

Good point (also, welcome to the CSSWG, it's great to have you participate).

I find it easier to reason about when thinking about individual elements than with fragmentainers, but it is true that we need to think through the implications on margin collapsing, and that your approach gives an easy way out of that problem. If we end up not taking your suggestion, I think we should be extra careful about what happens to collapsible margins with a different setting.

As for use cases, it seems to me that something like this is reasonable:

h1 {
  margin-top: 5em;
  break-before: right;
  margin-break: keep;
}
h2, hr {
  break-before: always;
  margin-break: discard;
}
@media print { hr { border: none; } }

This preserves a (large) top margin a the beginning of chapters, but drops it at the beginning of subsections (either marked by a lower level heading or by an <hr> element).

[fantasai]

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. https://drafts.csswg.org/css-box-3/#margin-trim

Wrt collapsing margins: if margin-break specifies discarding a margin, then all the margins that collapse with it would be discarded. Although I suppose we didn't really specify what happens when some of them are keep and some of them are discard... probably any with discard or auto should be discarded and any with keep should be kept.

CC @dauwhe @MurakamiShinyu @jensimmons @rachelandrew

[fantasai]

Actually, nevermind. That comment about collapsed margins is wrong, I was mixing it up with margin-trim. margin-break should operate independently on each margin. Note that all margins that collapse together are adjoining, so if one of them is adjacent to the break then all of them are. There's no order dependence.

[bernhardf-ro]

I'm not sure how multiple nested elements with collapsing top margins right after a page break should behave if their margin-break values vary.
I will try to put together some graphics to help further explain my issue as soon as time permits.

About margin-trim and fragmentation:
I think that for box-decoration-break: clone applying margin-trim per fragment may be the right approach, but I'm not really sure there.
However, for box-decoration-break: slice I think margin-trim should by applied per element.
But those are mostly my first impressions, I have not gone through use-cases or anything.
BTW, should that be its own issue?

[bernhardf-ro]

Could you please confirm the following conclusions/assumptions and our reasoning behind them:

1. "Margin collapsing is applied after margin-break." (margin-break affects separate margins while margin collapsing combines them)
2. "Margin collapsing effectively treats all boxes 'truncated' by margin-break like they had a margin-top of 0 specified." ("discard"/"truncate" in the context of margin-break generally means setting the used margin value to 0)

[fantasai]

@bernhardf-ro Wrt #3314 (comment) that is my expectation, yes. (Please note this is just a first draft, so nothing is fixed here, we're still accepting comments on how exactly it should work.)

[bernhardf-ro]

Thanks @fantasai for the confirmation (And belated thanks @frivoal for the warm welcome.)

With collapsing being applied last, I think the implementation side is safe. However, collapsing of nested elements seemingly changing truncated margins to non-zero values may be confusing for some authors. (In my personal experience margin collapsing, as it is, is already considered confusing by quite a few.) This may be solved by considering truncated margins to not be adjacent to any other margins or similar limitations to collapsing.

I still believe the simpler approach, setting the property on the fragmentation container, would eliminate these problems entirely. The desired result in the sample above can be achieved without using margin-break and the CSS would still be compact. And I have failed to come up with any more complex and realistic use-case that requires the finer control. Maybe someone else can.

Would adding properties for both elements and fragment containers, similar to *-self and *-items, be an option? It would provide the advantages of both, at, what seems to me, a very minor increase of complexity.