- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 11:58:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-multicol-2] `column-height` and nested fragmentation``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> rachelandrew: so this is what we just discussed, what happened if we have things broken into rows...<br> <TabAtkins> rachelandrew: the issue is what if the row is taller?<br> <TabAtkins> astearns: i think we can define that a column row is monolithic in a nested fragmentation context<br> <TabAtkins> fantasai: right now, if you don't set column-height, the multicol will generate multiple rows, one per page<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/11977#issuecomment-3135646117<br> <TabAtkins> fantasai: if we set column-height, that row is fragmented into two rows that are shorter. so when you generate a row, you take the maximum of ...<br> <TabAtkins> fantasai: the column-height is never taller than the remaining space on the page, we have to adhere to this<br> <TabAtkins> fantasai: within that constraint we ahve several options<br> <TabAtkins> fantasai: when you get to the bottom of the page and half a column height is remaining, you can decide that since column-height was set, i always want a full column-height, this row gets pushed to the next page<br> <TabAtkins> fantasai: another option is to clamp the column height to the remaining space on the page<br> <TabAtkins> fantasai: and we start a new one on the next page<br> <TabAtkins> astearns: not a fan of that one<br> <TabAtkins> fantasai: another is to split the row into two rows, the first takes up reamining space on th epage, the second takes the remaining space on the next page<br> <astearns> also not a fan<br> <TabAtkins> fantasai: i think these are all somewhat reasonable<br> <alisonmaher> q+<br> <TabAtkins> fantasai: not sure what i'd want as an author<br> <florian> q+<br> <TabAtkins> (i agree with alan)<br> <astearns> q+<br> <rachelandrew> q+<br> <TabAtkins> fantasai: possibly if it's close to filling the page, expand to fill the page.<br> <TabAtkins> fantasai: and if it's slightly too tall, shorten it a little bit to fit<br> <TabAtkins> fantasai: interesting thing about multicol is it takes the columns, you ask for 200px and you have 500px of space, we'll give you 250px columns, because that's what fits and looks good<br> <TabAtkins> fantasai: if we take that to the other axis, we can potentially tweak things so it looks reasonable<br> <TabAtkins> fantasai: but how do you make the decision?<br> <astearns> ack alisonmaher<br> <TabAtkins> alisonmaher: I don't like the idea of clamping, might not have neough space to actually put anything in there, leaving an empty row on the page<br> <TabAtkins> alisonmaher: out of the otpions, i prefer moving it ot th enext page, treating as monolithic<br> <astearns> ack florian<br> <TabAtkins> fantasai: i think it should at least get clamped by the page's full height<br> <TabAtkins> alisonmaher: yeah<br> <TabAtkins> florian: i think it depends on how you end up in this situation. you're designing for print, set up two rows, and you make it slightly too large. or designing for screen, it's doing something weird for print totally by accident.<br> <TabAtkins> florian: going by elika's point aobut column widths, maybe we can combine - for the one that moves to the next page, it lays out as normal, but the one that reamins does grow to fill the space<br> <astearns> ack astearns<br> <TabAtkins> fantasai: i think varying growsh could be uncomfortable<br> <TabAtkins> astearns: i think it would be ?? to take any part of the column-width determining algo and apply them to these rows<br> <fantasai> if you have a row that 90% fits, pushing it to the next page and then extending the previous would be uncomfortable<br> <florian> q+<br> <TabAtkins> astearns: authors have the ability to give a min width, max width, or any particular width<br> <TabAtkins> astearns: we should just use those to figure out what to do<br> <TabAtkins> astearns: if there's a definite or min height, and it doesn't fit, move on<br> <florian> q-<br> <TabAtkins> astearns: if there's a min height and it does fit, it stays there<br> <TabAtkins> astearns: then afterwards you can say what do do with the reamining one<br> <TabAtkins> fantasai: we don't have controls for those sizes<br> <TabAtkins> astearns: don't we have min-height?<br> <TabAtkins> fantasai: yeah, but those apply to the column container, not the column<br> <TabAtkins> fantasai: if you put max-height on a multicol container, it can contain multiple rows but they can overflow<br> <TabAtkins> rachelandrew: we're just talking about column-height right now<br> <TabAtkins> fantasai: yeah, but ther'es no min/max controls for that right now<br> <florian> q+<br> <astearns> ack rachelandrew<br> <TabAtkins> astearns: ah, k. I think we should just let things push to the next page if they overflow, then.<br> <TabAtkins> rachelandrew: i think i also agree with what florian said. the use-case that's most common for uncontrolled is someone pritning a webpage that was designed for the web<br> <TabAtkins> rachelandrew: if they're designing for print, they can just adjust it, they'll seee it before<br> <TabAtkins> rachelandrew: so treating it as monolithic is i think what's expected, from an author POV<br> <TabAtkins> florian: kinda agree, but maybe pushing back.<br> <TabAtkins> florian: you said treat it as monolithic and push it<br> <TabAtkins> florian: but for the thing left on the previous page, it might be useful to stretch to fill the page, maybe optional<br> <astearns> ack florian<br> <TabAtkins> florian: maybe the alignment properties control it<br> <TabAtkins> florian: stretch vs normal<br> <rachelandrew> I think alignment is another issue :)<br> <TabAtkins> florian: just feels like something we shoudl bea ble to choose between<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i don't think alignment is the right control for this.<br> <TabAtkins> fantasai: other intresting questions - at what point is it close enough that you want to tweak the height?<br> <astearns> s/be ??/be a mistake/<br> <TabAtkins> fantasai: in terms of distorting the page, hard to tell what'll distort it less. leaving a big gap can also be an unexpected answer.<br> <TabAtkins> fantasai: if you have a table that 90% fits, could be more disruptive to move it vs just shrinking it by 10%<br> <TabAtkins> fantasai: so going back to use-cases is important.<br> <TabAtkins> florian: typically, either you multicol is a little too short or tall for you page, but it's usually not a mix of things<br> <TabAtkins> florian: if it's just a little short, using alignment is normal, centered vs stretch vs bottom, etc<br> <astearns> q+<br> <TabAtkins> fantasai: if it's a litle too tall... if you aim for 3 and get just 2, that could be okay<br> <TabAtkins> fantasai: it's not if there are other things on the page<br> <TabAtkins> fantasai: like if your columns are all 33% tall, but one page has a bit of header...<br> <TabAtkins> rachelandrew: i think that coudl be controllable<br> <TabAtkins> florian: if one row doesn't fit, shorten it, yeah. but if there are multiple and the last doesn't fit, do you really want to shorten it? I think usually no<br> <TabAtkins> fantasai: so i think trying to make it look like it fits rather than having weird gaps is better<br> <alisonmaher> q+<br> <TabAtkins> TabAtkins: note that column-width only stretches to get wider, it never shrinks<br> <TabAtkins> fantasai: true, that's reasonable<br> <TabAtkins> astearns: i think the default of push to the next page and getting a gap is reasonable for now<br> <TabAtkins> astearns: if there's scenarios for handling a multiple of column-height not being an exact match for the container height, we should offer more controls rather than trying to intuit the author intent<br> <TabAtkins> rachelandrew: yeah, i think that's a future issue<br> <TabAtkins> astearns: where stretching can go wrong is if the columns are balanced and don't quite fill the page, stretching to fill the page can break teh balancing<br> <rachelandrew> +1<br> <TabAtkins> astearns: so i think we should start simple, and if there's a use-case for stretching to match the height, we provide an author control<br> <TabAtkins> florian: i think that's okay. but if one single row doens't fit, that can get squished<br> <astearns> ack alisonmaher<br> <astearns> ack astearns<br> <TabAtkins> fantasai: we already have rules for paginating multicol, it shortens the columns<br> <TabAtkins> alisonmaher: i agree this'll be an uncommon scenario<br> <TabAtkins> alisonmaher: if you were gonna stretch one of the columns to fill space, would we have to re-layout?<br> <TabAtkins> alisonmaher: if it's shorter, you'll end u pwith less content in th erow than if you hadn't printed?<br> <TabAtkins> alisonmaher: that's a bit weird<br> <TabAtkins> fantasai: we already do this. if you don't set column-height, and it ends up being 14" tall, and you paginate onto letter paper, we create columns on the first page, fill them, then put more columns on the second page for the reamining content<br> <TabAtkins> fantasai: so we don't cut it and shove to the next page, we fragment multicol to create more columns<br> <florian> q?<br> <TabAtkins> alisonmaher: with nested multicol today, you could set the constraight ahead of time, but here we're doing backwards because you don't know ahead of time. if there are multiple, do they stretch evenly across...? weird edge cases<br> <TabAtkins> fantasai: that's why i think shortening is better in general, you can tell that ahead of time<br> <TabAtkins> alisonmaher: then what if it doesn't fit?<br> <florian> q+<br> <TabAtkins> fantasai: if you cna't fit anything, then you treat it like monolithic.<br> <TabAtkins> fantasai: it would be nice, i think, if we had a min property so you could ensure we get more than one line of content<br> <TabAtkins> fantasai: but i think with that in mind, shrinking the column-height to the last column does fit is consistent with how we paginate multicol in general<br> <TabAtkins> fantasai: pretend the c olumn-height is infinite by default, and we're letting you shorten it<br> <TabAtkins> alisonmaher: so in the next outer fragmentainer, do you subtract it from the next?<br> <TabAtkins> alisonmaher: that would be inconsistent...<br> <astearns> ack florian<br> <TabAtkins> fantasai: not as much of an opinion there<br> <TabAtkins> florian: my sense if we might want a hybrid<br> <TabAtkins> florian: when you ahve set columnn-height, if 0 rows fit, you shrink that row (as we do today)<br> <TabAtkins> florian: but if several rows do fit, and the last doesn't, i'd do what alan said - treat as monolithic and move to the next page<br> <TabAtkins> florian: better than having two large column rows and one tiny one<br> <TabAtkins> florian: which probably isn't waht you want<br> <astearns> +1 florian. Current multicol pagination rules should only apply to a not-even-one row fits scenario<br> <TabAtkins> florian: maybe having controls for that later<br> <rachelandrew> +1<br> <TabAtkins> TabAtkins: agreed<br> <TabAtkins> fantasai: i propose we put this into the issue as a proposal and see what Morten thinks<br> <TabAtkins> fantasai: can revisit if he has more ideas, otherwise agree on it<br> <TabAtkins> fantasai: would also be good to ping Murakami-san to see if they have ideas<br> <TabAtkins> fantasai: so put it in as proposal rarther than resolution yet, to apply less pressure<br> <TabAtkins> rachelandrew: sounds good<br> <TabAtkins> florian: and make it clear that we're not pursuing it yet, but might go for controls about stretching/aligning into the empty space later<br> <TabAtkins> fantasai: might also be good to ask the princexml folks<br> <TabAtkins> rachelandrew: I'll put the comment into the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11977#issuecomment-3205979569 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 11:58:32 UTC