Re: [csswg-drafts] [css-multicol] Overflow in the block direction for continuous media (#2923)

> I (strongly) agree with the goal of this, but I have different proposal / syntax for getting here.
> 
> One thing I am not a fan of in the proposal in [#2923 (comment)](https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2566448417) is how it handles `(max-)height` / `block-size`: say you set the height of your multicol to be 10em. Depending on how many rows you get, the actual height might be 20em, or 30em (+ the gap size), and that's weird. What we are constraining is not the `height` / `block-size` of the multicol, it's the `height` / `block-size` of the rows, so using the `height` / `block-size` property seems off to me: that should care about the multicol as a whole, and a separate property should care about the height of the rows.

I don't think that was how it was meant to be read. The actual multicol height will be 10em, but it will be overflown with any additional rows. Using `height` / `block-size` both for sizing the multicol container and its rows does limit the possible uses, indeed. The use case it does support quite conveniently is when the multicol container has scrollable overflow. If it doesn't have scrollable overflow, the overflow will just overlap with subsequent content and look bad.

> Based on that notion, here's an outline my alternative proposal:

[...]

> name: column-row-height value: auto | <length [0,∞]> initial: auto
> 
> Sets available space in the block direction for column boxes, effectively acting as a cap on column box height.
> 
> auto: the available space is equal to the min inner height of the multicol container.
> 
> When 'column-row-height' has a value other than ''column-row-height/auto'', [=overflow columns=] are not added in the inline direction. Instead, additional column rows are created as needed to host the excess columns.
> 
> If you set both `column-row-height` to a non-auto value and `height`, your may have some leftover space in your multicol. https://drafts.csswg.org/css-align would tell you how to deal with it. (Details of how that works are interesting, but secondary to the concept as a whole.)

[...]

> * In a way, there's an implied `column-wrap: auto | nowrap | wrap` underlying this, where auto is the initial value, which resolves to nowrap if column-row-height is auto, and to wrap if not. I had it in my initial draft, but in practice I don't think there's much use for values other that `auto`, so I think this should not be exposed, at least in an initial version.

If `column-row-height` is `auto`, I really think we want to have a way of controlling where the overflow goes.

```html
<div style="overflow:scroll; columns:3; column-fill:auto; height:100px;">
  [... lots of text ...]
</div>
```

This will create additional columns in the inline direction. Back to the original use case, where we don't want to specify a column row size, but want overflowing content to establish additional rows, rather than creating overflowing columns in the inline direction... We want a way of achieving that. I think `column-wrap` is needed for that.

Quite oppositely of what you're thinking, I'm not sure what the `auto` value would be used for, but I see strong use cases for the two other values. :)

A `column-row-height` property would allow for some "interesting" scenarios in nested fragmentation, since this new thing "column rows" isn't the same as what happens when breaking inside a nested block fragmentation context:

```html
<!DOCTYPE html>
<div style="columns:4; column-fill:auto; width:460px; height:100px; gap:20px; line-height:20px; orphans:1; widows:1;">
  <div style="columns:2; column-fill:auto; column-row-height:120px; background:hotpink;">
    <div style="background:cyan;">
      A<br>B<br>C<br>D<br>E<br>
      F<br>G<br>H<br>I<br>J<br>
      K<br>L<br>M<br>N<br>O<br>
      P<br>Q<br>R<br>S<br>T<br>
      U<br>V<br>W<br>X<br>Y<br>
      Z<br>Æ<br>Ø<br>Å<br>1<br>
      2<br>3<br>4<br>5<br>6<br>
    </div>
  </div>
</div>
```

![Image](https://github.com/user-attachments/assets/4a403438-0b53-4d29-829c-9d9acc5ff3fa)

Should it look like this?

-- 
GitHub Notification of comment by mstensho
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2621146554 using your GitHub account


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

Received on Wednesday, 29 January 2025 09:45:11 UTC