-
Notifications
You must be signed in to change notification settings - Fork 757
[css-multicol-2] Initial pass at changes to the model section. #12544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@mstensho I couldn't add you as a reviewer for some reason but PTAL at this initial pass on the model section. |
css-multicol-2/Overview.bs
Outdated
| 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, |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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-heightis 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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
@mstensho thanks for all the discussion, I've updated this some more. |
There was a problem hiding this 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)?
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.