- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 05:52:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] impact of negative margins on running positions within a track, dense-packing, and alignment`, and agreed to the following: * `RESOLVED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: q about impact of negative margins on a running position when doing dense packing<br> <emilio> ... and alignment<br> <emilio> ... some great examples in the spec<br> <emilio> ... about item1 gets placed, item2 gets pulled up by the negative margin<br> <emilio> ... conclusion was that yes negative margins effectively shrink the size of the item, so they would affect<br> <emilio> ... then the question is if this has an effect on dense-packing gaps<br> <TabAtkins> https://private-user-images.githubusercontent.com/147667317/499050454-e73953de-23f2-4b74-9601-f1403465b75f.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjMwMTI2MTUsIm5iZiI6MTc2MzAxMjMxNSwicGF0aCI6Ii8xNDc2NjczMTcvNDk5MDUwNDU0LWU3Mzk1M2RlLTIzZjItNGI3NC05NjAxLWYxNDAzNDY1Yjc1Zi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD<br> <TabAtkins> 1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTEzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTExM1QwNTM4MzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iYzIwZWZhMTYzYzk1ODYzMDhhNGJlZTFmY2E1OWQyYWMyZDg0YzZhYWM1MmYxNjNiMjZlZjY1NDQ5MGQ1YjU4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.JVa21nv8RU_Od6DZ2OogFxQA699X50EDnve8qy44bsA<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/12918#issue-3496598507<br> <emilio> ... if you scroll at the bottom of ^, final image shows a masonry with a couple gaps<br> <emilio> ... new items on the lower gap, but also has a negative margin that pulls it up past the spanner<br> <emilio> ... should this reduce the size of the gap in any way<br> <emilio> ... we (me and elika) thinks it shouldn't<br> <emilio> ... geometrically it lives in the second gap, it's just small<br> <florian> q?<br> <astearns> ack emilio<br> <oriol> q+<br> <emilio> ... so if you use enormous negative margins you deserve what you get<br> <florian> q+<br> <astearns> ack oriol<br> <emilio> ... does it sound reasonable to anybody<br> <emilio> oriol: have a question. in masonry we keep placing items to the track is less filled<br> <emilio> ... but if the item we're placing has negative margins so that it ends up negative sized, should it be put in the most-filled track?<br> <emilio> TabAtkins: for the purposes of running position we should treat the item as zero-sized, if it's negative it wouldn't adjust the running position<br> <emilio> oriol: didn't you say the opposite<br> <emilio> ... that neg margin would shrink<br> <florian> q?<br> <fantasai> emilio: What Tab is sayaing is that if the item is 30px<br> <fantasai> ... [missed]<br> <florian> qq+ fantasai<br> <dholbert> Tab's proposal makes sense to me, FWIW.<br> <fantasai> emilio: But if negative margin -1000px, you cap the outer size at zero<br> <fantasai> oriol: So author sizes are never negative, then it's fine to replace<br> <fantasai> TabAtkins: I also have a proposal to fix flexbox to prevent flex main sizes from going negative for similar reasons<br> <emilio> fantasai: tab's proposal, if you place an item with negative margin so negative that would move the position up you would not adjust the position<br> <emilio> ... next item would be placed at the running position, not below the last item<br> <alisonmaher> q+<br> <plinss> q+<br> <astearns> ack florian<br> <emilio> florian: makes sense to me, not new that negative margins cause overlapping position, maybe they want it<br> <astearns> ack alisonmaher<br> <emilio> ... so agree with the proposal<br> <emilio> alisonmaher: wanted to clarify<br> <emilio> ... if you have a running position of 100px, and the negative margin would put it at 80 you put the max<br> <emilio> TabAtkins: effectively<br> <astearns> ack plinss<br> <emilio> alisonmaher: that's different than flexbox and block right?<br> <emilio> TabAtkins: yeah but I plan to fix flexbox<br> <emilio> plinss: for consistency, if you give it a positive margin that does increase the size<br> <emilio> ... so we're making negatives inconsistent right?<br> <emilio> TabAtkins: we're not, we are special-casing negative sizes, not margin<br> <emilio> fantasai: the running position can only move down<br> <emilio> [going through example]<br> <emilio> plinss: ok, I'm good with that<br> <emilio> PROPOSED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position<br> <kbabbitt> +1<br> <emilio> RESOLVED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12918#issuecomment-3525579517 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 November 2025 05:52:26 UTC