- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 21:24:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-2] Suppression of gaps/gutters across fragment breaks`, and agreed to the following: * `RESOLVED: if the gap overlaps a page break, or is th elast content before a break, suppress it (across all container types)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> kbabbitt: This isn't aobut gap-decoration, but about gap<br> <TabAtkins> kbabbitt: in Grid there's a sentence that states if a grid is fragmented, between tracks the gap is suppressed<br> <TabAtkins> kbabbitt: This was done to be consistent with margins, which makes sense if there are not gap decos<br> <TabAtkins> kbabbitt: with decos, it's weird, you lose the gap deco which might be meaningful<br> <TabAtkins> kbabbitt: also, firefox is the only engine that does it anyway. chrome and safari both slice the gap at the fragmentation point<br> <TabAtkins> kbabbitt: so there's no interop concenr<br> <TabAtkins> kbabbitt: so i'd like to propose instead of suppressing the gap, treat the gap as monolithic for fragmentation<br> <florian> q+<br> <TabAtkins> kbabbitt: so the gap is either entirely in rpevious or entirely in next<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> florian: for decos, having deco and not gap is werid<br> <TabAtkins> florian: but is there something wrong with ahving neither<br> <alisonmaher> q+<br> <TabAtkins> kbabbitt: the case i'm concerned is if you have an image as a gap deco (not specced yet, but want to think about now) the image could have info we don't want to lose<br> <emilio> q+<br> <TabAtkins> florian: reason i'm thinking about htis is we'll also have gaps with decos between rows of columns<br> <TabAtkins> florian: the number of gaps isn't predictable, depends on content<br> <TabAtkins> florian: so in a multicol context, you can't depend on a specific gap being there<br> <TabAtkins> florian: the deco *needs* to be decorative<br> <astearns> fwiw we have not prioritized preserving content in css-only decorations in the past<br> <TabAtkins> kbabbitt: my assumption there is the deco is only present if there is a gap to put it into<br> <TabAtkins> kbabbitt: so this would only makese sense in the context of the gap being there<br> <dholbert> q+<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i agree with florian that gap decors are meant to be decorative, if you put info in there you're doing it wrong<br> <TabAtkins> fantasai: I think current behavior makes sense<br> <TabAtkins> fantasai: i think it doens' tmake sense to introduce additional space due to moving the gap around<br> <TabAtkins> fantasai: i want to caution against reproducing scrolalble media presentation too much in paged media<br> <TabAtkins> fantasai: paged has its own reason for doing things<br> <florian> q+<br> <TabAtkins> fantasai: besides "no data loss", our first priority shoudl be "what do you want if this is printed"<br> <TabAtkins> fantasai: fragmentation is fundamentally a thing, it involves moving elements around, and it avoids putting in margins where there's already a break<br> <astearns> ack alisonmaher<br> <TabAtkins> fantasai: I don't think having a monolithic thing at the top or bottom of the page makes a lot of sense from a "fragmented flow" perspective<br> <alisonmaher> https://github.com/w3c/csswg-drafts/issues/6812#issuecomment-1006181635<br> <TabAtkins> alisonmaher: pointing to an issue we resolved a while back<br> <TabAtkins> alisonmaher: we resolved not to truncate margins at breaks for grid and flexbox<br> <TabAtkins> alisonmaher: i think kevin's behavior matches that better<br> <TabAtkins> alisonmaher: also, we treat top and bottom *borders* as monolithic, i think this follows suit<br> <TabAtkins> fantasai: we also attach the borders to the box they're from. only if you have such short pages you can't do that do the borders move to a different page<br> <astearns> ack emilio<br> <TabAtkins> emilio: i also think that removing the gap is the better behavior.<br> <TabAtkins> emilio: borders only attach to the beginning or end fo the box, i don't think they're comparable<br> <TabAtkins> emilio: you do skip the borders of all the fragments taht aren't the last<br> <TabAtkins> emilio: maybe this should be controlled by box-deco-break?<br> <TabAtkins> fantasai: if you had box-deco-break:clone you'd have a border there, not a grap<br> <astearns> ack dholbert<br> <TabAtkins> emilio: true<br> <TabAtkins> dholbert: thinking about a case that would kinda break<br> <TabAtkins> dholbert: someone using a grid to display tabular data, with gaps between them<br> <TabAtkins> dholbert: potentially each page would have different position fo the first content whther the monolithic gap stayed behind or not<br> <astearns> ack florian<br> <TabAtkins> dholbert: as you turned pages the first line would move up or down<br> <fantasai> +1 dholbert<br> <TabAtkins> florian: only indirectly in favor of the current beahvior...<br> <TabAtkins> florian: wrt deco conveying meaning, that's a problem. if your deco image conveys meaning, it needs alt text. it also needs to factor into reading order. etc<br> <kbabbitt> q+<br> <TabAtkins> florian: i think that's a subject best not dived into.<br> <astearns> q+<br> <TabAtkins> florian: putting in text images is probably wrong<br> <TabAtkins> florian: maybe there are arugments for keeping gaps even fi the image doens't convey meaning, but then i'd go with dholbert's argument<br> <TabAtkins> kbabbitt: points well taken<br> <fantasai> yes, it should be consistent<br> <TabAtkins> kbabbitt: i guess a question is we only do this for grid right now - should we also do it for wrapping flexbox or multicol?<br> <astearns> ack astearns<br> <TabAtkins> astearns: a use-case for grid decos where you might want kevin's behavior<br> <TabAtkins> astearns: if you're using the gap decos to group a set of items<br> <TabAtkins> astearns: you have a page that has top and side decos, and the bottom is on the break<br> <TabAtkins> astearns: if we suppress the gap, you don't get that separator<br> <TabAtkins> florian: can you place decos in some gaps but not others?<br> <TabAtkins> kbabbitt: a future version, yes<br> <TabAtkins> TabAtkins: definitely in the plan<br> <TabAtkins> florian: probably want to reflect that in the markup<br> <TabAtkins> TabAtkins: even if using subgrid, you might still want to use a gap deco for the visual separation, not a border or osmehthing<br> <TabAtkins> fantasai: you mmight want to attach it to the top or bottom, specifically, or show up on both sides, not just randomly show up on one or the othe rbased on layout happenstance<br> <TabAtkins> TabAtkins: sure, but all of those aren't "suppress"<br> <TabAtkins> kbabbitt: so it sounds like we might go with suppress<br> <TabAtkins> alisonmaher: what's the behavior? especially with image gaps<br> <fantasai> fantasai: The rule gets dropped, the break serves the purpose of separation<br> <fantasai> alisonmaher: then can the next row move up?<br> <fantasai> TabAtkins: No<br> <fantasai> alisonmaher: would it be confusing?<br> <fantasai> TabAtkins: There obviously wouldn't be enough space for it, so hopefully that's not confusing<br> <fantasai> astearns: We don't recompute after fragmentation truncates margins, for example<br> <TabAtkins> dholbert: similar scenario, you might have a gap that extends *almost* ot the bottom of the page with only a little bit of space left for the next row (so it gets pushed)<br> <TabAtkins> florian: where the gap fits and nothing else, you'd also remove the gap<br> <TabAtkins> florian: becuase it's not separating anything<br> <TabAtkins> kbabbitt: that makes sense to me, thinking of it like a margin<br> <TabAtkins> kbabbitt: i'm fine as long as we're consistent between this, flexbox, muilticol<br> <TabAtkins> astearns: proposal: if the gap overlaps a page break, or is th elast content before a break, suppress it<br> <TabAtkins> astearns: across all container types<br> <TabAtkins> RESOLVED: if the gap overlaps a page break, or is th elast content before a break, suppress it (across all container types)<br> <schenney> present-<br> <fantasai> dholbert: Clarify that we're just suppressing rendering, not the layout space it takes up<br> <dholbert> present-<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11520#issuecomment-2628423830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 21:24:30 UTC