- From: David Hyatt <hyatt@apple.com>
- Date: Thu, 16 Oct 2008 17:01:39 -0500
- To: robert@ocallahan.org
- Cc: Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org List" <www-style@w3.org>
- Message-id: <5D163A80-DD49-40A7-BC44-D67EEA817528@apple.com>
On Oct 16, 2008, at 3:44 PM, Robert O'Callahan wrote: > On Fri, Oct 17, 2008 at 8:50 AM, Håkon Wium Lie <howcome@opera.com> > wrote: > Also sprach David Hyatt: > > > Let's say you had way more text in your example, such that you > had 3 > > tiny columns and 24 more columns in the current implementations > (all > > spilling out horizontally). > > > > Are you proposing that those 24 extra columns would be stacked > > vertically in 8 overflowing rows of 3? > > Yes. > > > I think this would be ideal, since I could hit "page down" > > scrolling and read each "column page." > > Indeed. > > It's worth trying, and fairly easy to implement. > > One issue is that normally, when you scroll down by a page, Firefox > (and I think other apps) scrolls down by a little less than the full > page height so that some content that was at the bottom of the > previous page is visible at the top of the new page --- this gives > users some retained context. So if you do the obvious thing, say > html { height:100%; column-width:20em; }, repeated page-down will > not put the column tops at a constant offset from the viewport top. > We could special-case the page down amount for, say, scrollable > elements that use columns and the viewport when the root element is > using columns, but that's not a perfect solution. > > In general, when you want to put columns on an element that isn't > the only child of a scrollable container, I think this is not going > to work all that well. I don't know what would, but that's a problem > I'd really like to solve. Yeah that's a good point that there could be other unrelated content overflowing (like positioned descendants). I dislike the idea of adding to overflow-x and overflow-y to supply new overflow mechanisms. To me the values of overflow-x/-y are not about what specific type of overflow mechanism should be used, but just about whether the overflow is visible, invisible, reachable via an automatically appearing/disappearing overflow mechanism, or reachable via an overflow mechanism that is always present. That the overflow mechanism happens to be a scrollbar is really the issue, so maybe what's needed is a new CSS property that describes more explicitly what the overflow mechanism should be. dave (hyatt@apple.com)
Received on Thursday, 16 October 2008 22:02:22 UTC