W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: [css3-multicol] column overflow

From: Håkon Wium Lie <howcome@opera.com>
Date: Sat, 18 Oct 2008 09:40:01 +0200
Message-ID: <18681.37585.45456.864667@opera.com>
To: robert@ocallahan.org, "Tab Atkins Jr." <jackalmage@gmail.com>, "David Hyatt" <hyatt@apple.com>, "Alex Mogilevsky" <alexmog@microsoft.com>
Cc: www-style@w3.org

Robert O'Callahan wrote:

 > True, applying this feature to the viewport would solve a lot of use cases,
 > but it would also be useful for interior elements. For example you might
 > have content like a header or sidebar or framing UI that is always visible
 > with another element containing the "body text" which is paginated. Or you
 > might have a help pane that displays paginated.

Tab Atkins Jr. wrote:

 > On Fri, Oct 17, 2008 at 6:56 PM, David Hyatt <hyatt@apple.com> wrote:

 > > What's the reasoning behind restricting it to the root element?
 > 
 > Restricting it to the root element would eliminate a large amount of
 > worthwhile use cases.  Having a block in the middle of the page with
 > paginated content is actually something that I want, not just for this case,
 > but for many others.

This makes sense. 

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.

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.

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

  div {
    overflow-style: paginate;
    height: 0.8vh; /* or something */
  }

  http://www.w3.org/TR/css3-values/#relative0

 > 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? We could make rules for that,
e.g. that scaling or clipping is required.

I'd hate to have layers and layers of scrollbars inside pages inside
scrollbars etc.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Saturday, 18 October 2008 07:40:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:15 GMT