Skip to content
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-box-4] Applying margin-trim to fragmentation containers #10761

Open
fantasai opened this issue Aug 20, 2024 · 4 comments
Open

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

fantasai opened this issue Aug 20, 2024 · 4 comments

Comments

@fantasai
Copy link
Collaborator

Pulling out a comment from #3314 (comment)

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
Copy link

bfgeek commented Aug 21, 2024

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
Copy link
Collaborator

frivoal commented Aug 28, 2024

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 #3254

cc: @MurakamiShinyu

@w3c w3c deleted a comment from css-meeting-bot Aug 28, 2024
@css-meeting-bot
Copy link
Member

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.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-box-4] Applying `margin-trim` to fragmentation containers, and agreed to the following:

  • RESOLVED: margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box. if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom
The full IRC log of that discussion <dholbert> fantasai: we discussed this issue & related issue about text-box-trim on multicol containers a while back
<dholbert> fantasai: iank wanted some time to talk about how feasible it'd be to implement on the end side
<dholbert> fantasai: of containers
<dholbert> iank_: I synced up with morten. we're fine with the proposals. it does require backtracking
<dholbert> iank_: (the proposals for margin-trim and text-box-trim)
<dholbert> fantasai: the proposal is that margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box
<dholbert> fantasai: if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom
<dholbert> RESOLVED: margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box. if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Friday afternoon
Development

No branches or pull requests

5 participants