You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In multicol 1, overflow in continuous media happens in the inline direction, therefore if we restrict a multicol container by height and the content of that container creates more columns than will fit, new columns are created in the inline direction and we get a horizontal scrollbar. This is, in general, not what web authors want.
Overflow in the Block direction would enable something like the below image, where the additional columns are created below the initial multicol container.
In talking to web authors, there was an interest in this ability. Use cases would be to give the multicol container a height in viewport units in order to know that a reader would not have to scroll up and down to read the content, instead they could read one set of columns, scroll down and read the next. There are examples of people using vertical media queries to check for enough space to display columns such as https://css-tricks.com/guide-responsive-friendly-css-columns/#article-header-id-12
When discussing this, authors immediately jumped to the need/desire to control those overflow columns in some way, perhaps by being able to specify a different number of columns/column width in the overflow. For example having the first set of column boxes render three columns, and the second two.
The text was updated successfully, but these errors were encountered:
I have a work-in-progress draft spec to deal with putting additional columns in the block direction (and sizing things properly, so that these extra columns are not only overflow, but actually consume space and don't collide with what's after). I'll share as soon as it is a bit more fleshed out.
The feature is absolutely needed, but it begs one comment: allowing text to flow in the block direction is equivalent to assigning paged media behavior to continuous media for the purpose of multicols (in paged media, columns must overflow in the "block" direction).
Wouldn't it be both more general and easier to allow CSS to assign paged media behavior to continuous media? This would well support the use of CSS to create interactive presentations (slides) or newspaper like layouts, on screen; and it would immediately solve the multicol issue.
By the way, controlling whether columns have the same specs when moving to the next "page/block" remains an open question.
It's something we intend to look at in Level 2, I'm currently working to get Level 1 back to CR so it isn't something we can focus on right now. What would help would be if someone were willing to pay for the work - neither @frivoal nor myself are specifically paid to work on multicol. So we do it as we have time to do and the time I have I'm using to get the issues in the Level 1 specification sorted.
@rachelandrew Thanks for the quick reply. Okay, I don't think I can afford to pay you 😅but, if it is at all helpful, maybe I can write about it publicly, and moot some ideas for the syntax. I am already exploring some existing ways to control column display based on circumstance, such as using quantity queries: https://codepen.io/heydon/pen/PvXJGv.
Yes - we are always interested in ideas and particularly in use cases for this stuff! Do post a link back here, it can take a while for things to get worked on but we do take the contributions of folk into account when we get to it.
I just stumbled on this peculiarity of the spec, and I want the spec to follow firefox, and historical webkit behaviour: extra content overflows vertically as if columns are balanced, and it respects orphans css prop.
Otherwise, I see no way how to square it with #4689 and spec-compliant column-fill, an min-height behaviour.
How overflow-y: auto can work if columns overflow an y-scrollable container element? Columns will overlow on the right, while y-direction will be occupied by empty space equivalent to height of overflown column?