- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 24 Jun 2026 16:30:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-break-3] Should broken boxes always be extended to fill the gap?`, and agreed to the following: * `RESOLVED: accept the PR` <details><summary>The full IRC log of that discussion</summary> <emilio> fantasai: this was brought up by somebody noticing that the way spanning items fragment looks very awkward<br> <emilio> The problem is that if there's a grid / table item spanning multiple rows. If we fragment in the gap, the spanner continues through the empty space<br> <emilio> ... they were wondering whether there could be a way to skip that gap<br> <emilio> ... my reading is that I don't really think there's a strong reason for the current behavior<br> <alisonmaher> q+<br> <emilio> ... so rather than adding a switch we should change the behavior<br> <emilio> ... so if you fragment in the gap between two rows<br> <emilio> ... the space between the gap and fragmentation break is not usable for the item<br> <emilio> fantasai: it'd give the item slightly less available space<br> <astearns> ack alisonmaher<br> <fantasai> s/between/belonging to/<br> <emilio> alisonmaher: I think if you want to do this it shouldn't be fragmentation specific? Spanners span gaps<br> <emilio> ... It seems we need to come up with a different type of spanner<br> <emilio> ... I think this would break, the spec says the container continues in the grid fragmentainer<br> <emilio> ... Doesn't seem it needs to be fragmentation specific<br> <astearns> ack fantasai<br> <astearns> q+<br> <emilio> fantasai: I think what you're describing still looks weird<br> <emilio> ... and it'd look better with the proposed behavior<br> <emilio> ... as for something more general, I do think this is more about fragmentation<br> <emilio> astearns: with the example in comment 1 there isn't a gap but if they were and the spanner had ??, and when it's not fragmented 1/2/3 are in the gap<br> <emilio> ... with this change, when you fragment the content shifts relative to row #2<br> <astearns> ack fantasai<br> <emilio> ... there used to be 4 and now there are 3 corresponding to row #2, which I think is ok but something to think about<br> <emilio> fantasai: that's a good point, we should make the gap disappear at the break<br> <fantasai> s/should make/already make/<br> <lea> +1, there should be no gap there at all, that seems like a bug<br> <emilio> astearns: not entirely sure I agree with alisonmaher, we could fix this fragmentation issue then determine whether the effect is something people would want in non-fragmented grid<br> <emilio> alisonmaher: I think if the spanner is sized explicitly it's going to be cut it off early with but not without fragmentation then it could overflow into the next fragmentainer<br> <emilio> ... so I think there are going to be undesirable consequences<br> <emilio> astearns: I see two ways forward: we accept this change and changing the default behavior and see how it looks with other behaviors, then open an issue for this in non-fragmented context, or don't make a decision today and look at it in the issue<br> <emilio> lea: I said that there should be no gap at all there<br> <emilio> ... between the two things what's proposed is better, but the best solution maybe should be no gap<br> <emilio> fantasai: wdym?<br> <emilio> lea: if it fragments I would expect no gap at all<br> <emilio> fantasai: there's the 4px gap you specify, but then there's the fragmentation gap<br> <emilio> lea: I meant the specified gap<br> <emilio> fantasai: that does disappear<br> <kbabbitt> correct, anything specified via `gap` properties is dropped<br> <astearns> ack fantasai<br> <astearns> ack lea<br> <emilio> fantasai: If authors have fixed size items they're not going to line up, that's why we have stretch sizing<br> <emilio> ... i.e. if you have two rows and [??]<br> <emilio> ... authors shouldn't be writing code like that<br> <emilio> ... the browser should do the work for you in that case<br> <emilio> ... I'm more concerned about other situations like the background [??], but not the explicitly sized spanner<br> <emilio> ... because the gap already disappears<br> <emilio> astearns: alisonmaher would you be ok changing the default fragmentation behavior just for now?<br> <fantasai> s and [??] a spanner sized explicitly to perfectly match the height of the rows and the gap ...<br> <emilio> alisonmaher: not super convinced this is necessarily the right solution but if hopes want to try it I don't object<br> <fantasai> s/and [??]/ and a spanner sized explicitly to perfectly match the height of the rows and the gap ...<br> <emilio> astearns: I'd prefer trying to change this and get more eyes<br> <fantasai> -> https://github.com/w3c/csswg-drafts/pull/13810<br> <kbabbitt> astearns: fantasai are you ok with the PR as is or do you want a more general resolution?<br> <kbabbitt> fantasai: I think this PR captures what we're trying to do, happy to take suggestions for improvement<br> <kbabbitt> ... if the fragmented item is a grid or table item that splits 2 or more rows, gap should not extend beyond those 2 rows<br> <kbabbitt> ... some editorial tweaking we can make<br> <kbabbitt> astearns: any objections to accepting the PR and changing the default behavior?<br> <kbabbitt> RESOLVED: accept the PR<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12801#issuecomment-4791494295 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 June 2026 16:30:25 UTC