Re: [csswg-drafts] [css-grid-3][masonry] Effect of negative bottom margins on running position + dense-packing (#13164)

The CSS Working Group just discussed `[css-grid-3][masonry] Effect of negative bottom margins on running position + dense-packing`, and agreed to the following:

* `RESOLVED: running position is updated by the outer size floored to zero`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> cepan:<br>
&lt;sgill> cepan: question is in case where we have an item with negative bottom margin that exceeds the following item that would be placed<br>
&lt;sgill> do we want following item to be capped so that the content edge by the first item or so that the running position cannot go negative<br>
&lt;sgill> already resolved running position cannot go back<br>
&lt;sgill> original proposal was to have content edge match but maybe it would make sense to have the running position at 0<br>
&lt;sgill> want to essentially have running position get capped at 0<br>
&lt;alisonmaher> q+<br>
&lt;dholbert> q+<br>
&lt;astearns> ack alisonmaher<br>
&lt;sgill> following items would get placed depending on running position<br>
&lt;TabAtkins> q+<br>
&lt;sgill> alisonmaher: makes sense but how does this work with dense packing?<br>
&lt;sgill> TabAtkins: we should place with outer size of box<br>
&lt;astearns> ack dholbert<br>
&lt;sgill> shrink based on margins capped to 0<br>
&lt;sgill> dholbert: when talking about capping running position are you talking about the delta or the distance from the end of the previous item?<br>
&lt;sgill> cepan: distance from end of previously placed item<br>
&lt;sgill> dholbert: you said content edge but maybe border edge?<br>
&lt;sgill> TabAtkins: we place with the outer edge<br>
&lt;sgill> dholbert: item at the end of lane with negative margin to margin box is in the middle of the box<br>
&lt;sgill> in that scenario what is the thing we are capping to 0?<br>
&lt;sgill> cepan: if we have an item with margin bottom -80px, we clamp running position change to be 0<br>
&lt;sgill> running position cannot go backwards<br>
&lt;sgill> next item could go above it<br>
&lt;sgill> could be a case where the negative margin doesn't exceed<br>
&lt;astearns> [fantasai draws the example from Hoch’s comment, then talks about what happens after that]<br>
&lt;sgill> florian: overlap is fine but climbing up the lane is not<br>
&lt;astearns> q?<br>
&lt;sgill> fantasai: that clearance we are applying you cannot put dense packed things into it<br>
&lt;TabAtkins> so in short: the running position is updated by a delta of the new item's outer size; this delta is clamped to 0px.<br>
&lt;astearns> ack TabAtkins<br>
&lt;oriol> Didn't we already resolve this in a previous F2F?<br>
&lt;sgill> TabAtkins: purpose of these adjustments is that when we are updating the item, the delta for the running position should be capped to 0<br>
&lt;sgill> cepan: we had a negative margin top resolution but not bottom<br>
&lt;fantasai> RESOLVED: running position is updated by the outer size floored to zero<br>
&lt;dholbert> s/capped/clamped/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13164#issuecomment-3820703184 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 29 January 2026 22:12:51 UTC