Skip to content

Conversation

@rachelandrew
Copy link
Contributor

There will be more to do here, and I want to add some images, but here's a first pass at the basics so we at least have lines and rows defined.

I haven't added the stuff about nested multicols here, not sure if it's the right place.

@rachelandrew
Copy link
Contributor Author

@mstensho I couldn't add you as a reviewer for some reason but PTAL at this initial pass on the model section.

The <dfn export>column height</dfn> is the length of the column box in the block direction.
All column boxes in a line have the same column width,
and all column boxes in a line have the same column height.
All column boxes in a row have the same column width,
Copy link
Contributor

@mstensho mstensho Jul 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Column boxes are inside a line (which is inside a row). Why this change? It's also wrong in some cases, actually, since fragments generated from the same multicol container (when nested inside another fragmentation context) may have different widths or heights. Since each multicol fragment establishes a separate line for its columns (right?), if it has any columns at all, the width and height of column boxes are the same within a line (but not necessarily within a row).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I think this depends on where we see the height as happening.

  • The column-height is 100px.
  • There's a spanner, it is 20px tall.
  • We now have two multicol lines, one above and one below the spanner.
  • If the column-height is what defines the row height, those lines are each 40px tall.

Therefore the height the author cares about is the height of the column, because that defines the height of the row. If you consider a block direction carousel where each row is 100vh, the author needs to set the column-height to 100vh, which defines the row size. The only reason the row would be a different size would be if we had to stretch due to a giant spanner (if we go that way).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming that we have the same amount of content before and after the spanner, then yes, the columns will all have a height of 40px, both before and after the spanner.

<!DOCTYPE html>
<div style="columns:3; column-fill:auto; column-height:100px; line-height:20px;">
  before
  <div style="column-span:all;">spanner</div>
  after<br>after<br>after<br>after<br>after<br>
</div>

There's a multicol container. It has one row that is 100px tall. The row has one line, one spanner, then another line.
The first line is 20px tall, the spanner is 20px tall, the second line is 60px tall. The columns in the first line is 20px tall. The columns in the second line are 60px tall. Therefore all columns in a row do not necessarily have the same column height.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean... maybe we need to more strongly define column boxes vs columns? As it's the column that has the height, depending on how many lines there are multiple column boxes within each column. I think that's where I'm confusing things anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused now. :) Multiple column boxes within each column? In my mental model, there's no distinction between "column" and a "column box". In my example above, there should be one column (or column box) above the spanner (there's just one word there, after all), and two columns (or two column boxes) below the spanner. Are you thinking that the first column box above the spanner and the first column box below the spanner form one column? Or something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That won't work for the carousel type use cases. You'd end up with a spanner outside of the "page" which would be weird.

It would be fine for the simplest use case of just making sure people don't need to scroll up and down to read, but if we want an entire screen to be a row AND you had a spanner, you'd then end up with the spanner off the bottom of the screen.

Also it would definitely stop column-span: <integer> ever being a thing.

We need the lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To explain about column-span: <integer> the most likely way (in my mind) to implement that would be in conjunction with page floats. So you'd have a three column multicol container, and an element spanning two columns floated top right. That's a super common magazine type layout and the sort of thing people raise (for example #11474).

That would not work if spanners were this weird thing that existed outside of rows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do carousel type use cases even want spanners at all, though?

Spanners are taken "out of flow" anyway, and I see no strict reason for them having to belong inside a row. Yes, I think page float is the use case for column-span: <integer>. Anything else (non-floated) would be weird, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be such an unexpected behavior for spanners to do that, to immediately lose the nice "set of pages at x height" because there's a spanner seems bad. I do thing that a carousel type layout using page floats would likely be something people want if we ever go there, because there's some nice (and fairly obvious) patterns you could achieve with that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that makes sense. So I guess we need lines and rows. Sorry for the detour.

And deal with page floats later. :) You seem to want them to be contained by rows? They don't need to live inside multicol, though (in which case there'll be no rows). E.g. when printing. We may want to top/bottom align a page float. When printing with multicol, we might want them to span a certain number of columns. If there's no column wrapping set, there'll still be just one giant row, but we then want the page floats to be aligned with some page edge, since the row is irrelevant in that case.

@rachelandrew
Copy link
Contributor Author

@mstensho thanks for all the discussion, I've updated this some more.

Copy link
Contributor

@mstensho mstensho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also include wording about disallowing wrapping for fragmented multicols (paged media / nested multicol)?

@rachelandrew rachelandrew merged commit eff256b into main Aug 19, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants