Open rachelandrew opened 6 years ago
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.
When it comes to styling the next row(s) of columns differently, I think this will be solved by continue: fragment
and ::nth-fragment
](https://drafts.csswg.org/css-overflow-4/#fragment-pseudo-element). That isn't solved yet, but we're making baby steps towards it in css-overflow-3, since line-clamp
starts to put in place some of the related machinery.
For paged media, please make the default height of the multicol container be "to the bottom of the current page".
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.
What can I do to help push this along?
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.
@rachelandrew Here's the post: https://every-layout.dev/blog/multi-column-manipulation/
P.S. I tried using a CSS regions polyfill to emulate block overflow, but couldn't get the polyfill itself yo work. I may revisit 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 https://github.com/w3c/csswg-drafts/issues/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?
I cannot fathom what purpose this logic serves.
End user here. I am using multicol for wide displays (e.g. 4K) when a user maximizes their browser window. This is to reduce difficulty in reading extra long lines of text.
I did run into a pecularity with this feature on iPad and I'm not sure if it's a bug or a feature. On the following web page, there is a line chart and a pie chart that just happen to straddle the column break. The page displays correctly at first, and sometimes when I scroll the line chart gets moved to the top of column 2 and the pie chart is displayed on top of the line chart. (not supposed to happen) Here's a screenshot:
Multicol seems to work as expected everywhere else that I have tested, it's just a physical iPad where I am seeing the issue, and only sometimes. I'm wondering if it's the particular webkit that runs on the iPad or some other issue. Environment is Chrome 126.0.6478.153 running on iPadOS 17.5.1.
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.