New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bernhardf-ro opened this Issue Nov 13, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@bernhardf-ro

bernhardf-ro commented Nov 13, 2018

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 frivoal added the css-break-4 label Nov 14, 2018

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Nov 14, 2018

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

This comment has been minimized.

Contributor

fantasai commented Nov 15, 2018

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

This comment has been minimized.

Contributor

fantasai commented Nov 15, 2018

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.

@fantasai fantasai added the css-box-3 label Nov 26, 2018

@bernhardf-ro

This comment has been minimized.

bernhardf-ro commented Dec 6, 2018

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

This comment has been minimized.

bernhardf-ro commented Dec 7, 2018

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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment