- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 23:31:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-multicol] Overflow in the block direction for continuous media`, and agreed to the following: * `RESOLVED: start specifying column-height` <details><summary>The full IRC log of that discussion</summary> <nicole> rachelandrew: speccing overflow in block direction for multicol<br> <nicole> rachelandrew: partially becuases of the carousel work, and partially because it can go in different directions. Rachel put proposed spec in the issue as a starting point<br> <nicole> rachelandrew: modeled after flex<br> <astearns> proposal: https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2566448417<br> <nicole> rachelandrew: modeled after logical container. Instead you could opt to use column wrap<br> <fantasai> +1 for a row-height property<br> <astearns> florian's: https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2620334162<br> <nicole> rachelandrew: has a different proposal. what should we do, which looks best?<br> <florian> q+<br> <astearns> ack florian<br> <nicole> florian: want to have this ability. multicol having overflow columns in inline dir isnt' what people want most of the time. Having multiple rows of multicol is extremely desirable.<br> <nicole> florian: constrain height, overflow in block direction rather than inline direction<br> <kizu> q+<br> <nicole> florian: are they simply overflowing. Will they clash? Or whether you simply grow the multicol despite the constrained height<br> <nicole> florian: should the rows add height?<br> <nicole> florian: proposes a new prop to constrain the height of the row of the multicol. column-height or column-row-height would work well.<br> <nicole> florian: column-row-height: 10em<br> <nicole> florian: if you also set the multicol height, you use all the css tools to deal with how to lay them out<br> <TabAtkins> yup, +1 to column-row-height<br> <nicole> florian: not sure what short hands should be<br> <astearns> ack fantasai<br> <nicole> florian: how to make it work with gap and other properties needs to be worked out<br> <florian> q+<br> <nicole> fantasai: doesn't want an overflow model for this feature (in flow content). Don't conflate sizing the box with content inside the box. Prop that sets column height is the right thing to do<br> <astearns> ack kizu<br> <TabAtkins> ah yeah, column-height is shorter and just as right<br> <astearns> q+<br> <nicole> fantasai: likes column-height<br> <nicole> roman: wants this feature. Could imagine automatically fragmenting so that each item goes into the overflow container<br> <astearns> ack florian<br> <nicole> roman: use case to fit everything in viewport so it paginates properly<br> <nicole> florian: not incompatible with having a property<br> <TabAtkins> (i do think it would be nice to have a `column-height: auto` that matches the height of the nearest scroller)<br> <fantasai> s/use case/but more common is use case of having it in-flow,/<br> <nicole> florian: if you set it to auto it would go in the block direction otherwise inline<br> <nicole> florian: row-height instead of column-height because we might want to use column-row-count later, but won't insiste<br> <rachelandrew> q+<br> <nicole> fantasai: column-height and column-width as a pair seems better<br> <nicole> fantasai: authors won't think about columns as explicitly as rows<br> <florian> q+<br> <nicole> astearns: florian mentioned overflow in inline dir, but thinks it is the wrong way to talk about it. We are fragmenting in the inline direction or block direction. As you fragment columns now they can overflow in inline direction.<br> <nicole> astearns: when we add this you will be able to fragment in the block direction<br> <nicole> astearns: but it also might overflow, to put the content in the new contents<br> <nicole> florian: agree overflow isn't quite the right word. Neither is fragmentation. Fragmenting the content of the multicol, and deciding where to place them. Whether they overflow depends where you place them and what else is there.<br> <nicole> florian: rachelandrew proposed column wrap, whatever we call it, they describe where the extra content goes (block or inline direction)<br> <astearns> ack rachelandrew<br> <astearns> ack astearns<br> <astearns> ack florian<br> <nicole> astearns: doesn't agree with fantasai that ___ will be rare, he thinks authors will want to do it at the outset<br> <nicole> rachelandrew: what happens if you have set a height on multicol and then you set column height and row height. And then you have too many things to fit in the container. Answer could be that it overflows<br> <nicole> florian: yes<br> <astearns> s/___ /choosing how many rows of columns you want/<br> <florian> q+<br> <astearns> ack florian<br> <nicole> rachelandrew: are we bringing in too much extra complexity? Is it getting to be like regions. Not against direction, just concerned about complexity.<br> <nicole> florian: yes it would overflow, like any content that doesn't fit would<br> <nicole> florian: doesn't matter how many rows cols you put in there<br> <nicole> florian: if it is too big, you have other tools to deal with extra space<br> <TabAtkins> I definitely think tying this explicitly to overflow *is* making it too complex. Just adding more columns to the content seems like the most straightforward way<br> <nicole> astearns: proposed resolution to start specifying this using column-height<br> <nicole> rachelandrew: happy with that<br> <kbabbitt> 👍<br> <nicole> RESOLVED: start specifying column-height<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2625930018 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 23:31:25 UTC