Re: [csswg-drafts] [css-gaps-1]: Suppression of gaps/gutters across fragment breaks with spanning item (#13362)

The CSS Working Group just discussed `[css-gaps-1]: Suppression of gaps/gutters across fragment breaks with spanning item`, and agreed to the following:

* `RESOLVED: close, no change`

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> fantasai: I thought we already specced this<br>
&lt;bramus> oSamDavis: we resolved if a gap overlaps the ??? w eought to suppress it<br>
&lt;bramus> … in the image there is such a candidate<br>
&lt;bramus> astearns: so we had that resolution<br>
&lt;bramus> oSamDavis: I noticed there is a caveat with that<br>
&lt;bramus> … whcih item migh tspan that is split accross a break, like in this example<br>
&lt;bramus> … if this break were to occur on a fragment break then ???<br>
&lt;bramus> … if we attempt to supporess tha tgap, t might suppress a chunk of that item<br>
&lt;bramus> … and so my proposal is to add an exception to suprpress an item when there is a spanning item<br>
&lt;bramus> … crossing the gap<br>
&lt;bramus> fantasai: suppressing a gap does not mean clip contents tha tis not the gap<br>
&lt;bramus> … just means tha tgap  is zero height<br>
&lt;bramus> … does not mean cutting up things<br>
&lt;bramus> … if you suppress a gap or margins (which we do during fragmentation) we dont clip out.<br>
&lt;bramus> … treat margin as 0<br>
&lt;bramus> … the gap gets supppress but dont cut spannin gitem<br>
&lt;bramus> … just do layout as if the gap has 0 height<br>
&lt;fantasai> s/clip out/clip out adjacent content like floats or spanning items/<br>
&lt;bramus> oSamDavis: so you are saying that this item would be pushed up?<br>
&lt;bramus> fantasai: the spanning might get shorter as it no longer has to span the gap<br>
&lt;bramus> … if its a fixed size maybe the next item gets taller, but you have to do layou tas if th egap has a zero height<br>
&lt;bramus> … when you framgne tyou ??? dont want to cut ?? you cant not do layout around gragment breaks<br>
&lt;bramus> oSamDavis: in this case then ???<br>
&lt;bramus> fantasai: potentially<br>
&lt;bramus> … say tha tspanning image is a tall image controlling hte height of th e rows, its not gonna get shorter bu tthe 2nd row migth get taller.<br>
&lt;bramus> … layou thas to adapt … just lik ewe are fragmenting here<br>
&lt;bramus> … can take space way, can also add space … have to do layout, cant just cut things<br>
&lt;bramus> oSamDavis: so if the taller spanning item was cuttable then it would shrink, i fnot then the other item would expand<br>
&lt;bramus> fantasai: yeah<br>
&lt;bramus> … you have to layout the content and then hceck if everything fitted and push to next page if not<br>
&lt;bramus> … if there is content inside the spanning item, the marging idsappears if there was one<br>
&lt;bramus> … or it might be an img that get sliced, so ???<br>
&lt;bramus> alisonmaher: in blink, we dont relayout after fragmenting. we capture the coords and that info then ???<br>
&lt;bramus> fantasai: so what do you do then?<br>
&lt;bramus> iank_: the probmem with fragmentation is you need to know where you are positioned in order to fragment<br>
&lt;bramus> … and, you can only apply heirustics to get this to work<br>
&lt;bramus> … so what we do, we only allow rows to expand from – we capture entire grid, then llook at where fragmentation will happen, then try and fragment the content, and then potentially expand the row<br>
&lt;bramus> … so we dont re-run trap sizing<br>
&lt;bramus> s/trap/track<br>
&lt;bramus> fantasai: i guess you just expand the row on the 2nd page with ?? gap<br>
&lt;bramus> oSamDavis: this second to last row then would expand, and that would be 0 px<br>
&lt;bramus> fantasai: ideally you would also be able to shrink a little bit<br>
&lt;bramus> … and shift everything up<br>
&lt;bramus> … but if you cant it seems fine to do that<br>
&lt;bramus> oSamDavis: sounds good, expand<br>
&lt;bramus> … fine with the idea of expanding the rows<br>
&lt;bramus> astearns: so there is going to be no exception for gap supppression for fragmentation<br>
&lt;bramus> … so we close no change?<br>
&lt;bramus> fantasai: yeah<br>
&lt;bramus> oSamDavis: Yea<br>
&lt;bramus> RESOLVED: close, no change<br>
</details>


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


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

Received on Wednesday, 28 January 2026 23:59:23 UTC