- 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