- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 28 May 2015 15:46:43 -0700
- To: Koji Ishii <kojiishi@gmail.com>
- Cc: W3C www-style mailing list <www-style@w3.org>
On Wed, May 27, 2015 at 3:34 AM, Koji Ishii <kojiishi@gmail.com> wrote: > Thank you all WG members for taking time to discuss on this topic in > the F2F. For those who did not attend the F2F, this issue is about > auto-multicol behavior[1] and here's the IRC log[2]. > > I'm really impressed by the insights by Rossen, Steve, Simon, dbaron, > florian, and all who helped this discussion. I didn't have that view > point by myself. > > That changed my proposal from "defer" to "move to other specs". The > more this feature is useful, as already suggested in the IRC, the more > this feature should be available in other cases than just orthogonal > flows, and authors should be able to use it. > > I'm not sure which spec it should move to, probably fragments, > overflow, or multi-col, that we could discuss further. Why is this needed for anything else? I don't recall that being discussed in the meeting. The only reason for "auto-multicol" is to handle the case of "infinite inline-axis space" in a way that's not super user-hostile. The naive behavior *is* extremely user-hostile; it effectively makes the orthogonal element max-content in the inline axis (requiring the user to scroll back and forth to read lines of text; we all know how terrible this is when reading some accidentally-long <pre> text) and, if there's enough block-axis content, overflowing in the page's secondary scrolling direction (the one that's annoying to scroll in). That situation never occurs anywhere except orthogonal flows, because the inline axis space is always finite when all the writing modes match. ~TJ
Received on Thursday, 28 May 2015 22:47:30 UTC