Re: [css3-multicol] column overflow

On Sat, Oct 18, 2008 at 3:28 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, Oct 18, 2008 at 8:40 PM, Håkon Wium Lie <howcome@opera.com> wrote:
>
>> However, there would also be much room for abuse. For example, this code:
>>
>>  div {
>>    overflow-style: paginate;
>>    height: 600px;
>>  }
>>
>> would be a terrible user experience on a small screen -- you'd have to
>> scroll to find a button to press to get to the next page.
>
>
> Not necessarily --- a UA could arrange for the controls to appear inside
> the screen edge.
>

That wouldn't work well if there were multiple paginated boxes on the
screen.  Which would, itself, be a bad user interface, but still.  The
paging buttons really need to stay in a definite spot relative to the paged
box, I think.

But anyway, if 'paginate' was not available, the author would probably use
> regular scrollbars instead, which are susceptible to the same problem.
>
> On the topic of buttons, where do they go and what do they look like?
>> Having a UA-provided simple set of buttons would make sense, but -- as
>> we know -- some authors want pixel-perfect control.
>
>
> Authors don't get pixel-perfect control over scrollbars today, far from it.
>

It'll certainly annoy some, but yeah, we have far from pixel-perfect control
today over UA elements, and this is a great thing.

For placement, we really want to mimic the current situation with
scrollbars, where they completely fill an edge that nothing else gets to sit
within.  Probably just along the bottom of the box.  Something like most PDF
viewers, with a page count, along with back/forward/first/last buttons?
 That's roughly what people are used to on semi-paged content such as
webcomics today.

The 'vh', which refers to the height of the viewport, may be helpful
>> in making scalable designs:
>
>
> Indeed.
>

Agreed.


> > Adding 'paginate' to overflow-style sounds great. However one issue which
>>   > occurred to me is that even if the content is paginated, a single
>> "pagelet"
>>  > can still overflow in the block progression direction, so authors might
>> want
>>  > to control the visibility of the block progression direction scrollbar
>> even
>>  > in paginated mode.
>>
>> How could it overflow? A tall image?
>
>
> Depends on the UA, because CSS does not currently define how pagination
> works. But in Gecko, for example, a single very tall line (say containing an
> inline-block or inline-table) will not break across pages, and I don't see
> us wanting to change that.
>
> We could make rules for that,
>> e.g. that scaling or clipping is required.
>
>
> Scaling sounds terrifying. Clipping would often be OK. But allowing
> vertical scrolling might also be desirable, sometimes. I guess it would
> confuse the user since now there are two ways to go "down". Hmm. If the
> paginated element (or viewport) is resizable (say by resizing the window),
> the user could usually resize to see the page-overflowing content. So
> perhaps initially it would suffice to just clip.
>

I don't think there would be any user-confusion.  It's only in the author's
mind that "next page" means "further down the content stream".  To us users,
a new page is completely orthogonal to the direction of any scrolling that
may happen.

This is actually a bit of a conundrum.  Paginating *is* an overflow style,
no question about it.  But on the screen we're not limited like we are in
the page - we don't *need* to say "within the page box, everything is
clipped".  We can absolutely allow a secondary overflow mode for things that
are too big for a single page, but won't wrap to a second one. Should this
be a new property?  An amendment of the current overflow-style to allow two
modes (possibly separated by a /)?  I'm not sure which is preferable.

~TJ