Re: [css3-multicol] overflow inside multicol elements

On Mar 5, 2013, at 5:23 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Wed, Mar 6, 2013 at 9:12 AM, David Hyatt <hyatt@apple.com> wrote:
> Note that if the multicolumn block has overflow:hidden (which again will be common when you're paginating an entire document, you'll see a bad-looking slice with your approach as well), or you won't see the content at all if it is fully out of view.
> 
> True, but if the relative positioning isn't too large, authors can work around that by adding padding to the multicolumn element.
> 
> (3) Vertical offsets are in the flow, relative positioned object paginates at its final position.
>     (a) Pros - Content is never lost, even when the column block is clipped. No bad slices ever occur.
>     (b) Cons - Relative positioning is being taken into account prior to layout, which does not match the current spec.
> 
> Also, this is likely to be insanely hard to implement IMHO.
> 
> So your use-cases revolve around situations where an author wants to render content they don't control with vertical breaks, there's a real risk it contains transforms or rel-pos that would extend outside any reasonable margins/padding, and scrolling to view such transformed/rel-pos content is not acceptable for some reason, so they're willing to visually slice and accept poor vertical breaks in other situations.

This is my concern yes. In WebKit right now, far and away the most common use case for our multi-column layout implementation is for pagination of content that was not necessarily authored with the intent of being displayed in columns. The most prominent example of course is iBooks on the iPad. In that particular case it was iBook's decision to paginate horizontally. The authors of the EPUBs are of course agnostic regarding the pagination direction, and so having rendering of EPUBS change across devices just because the pagination direction happens to be horizontal is pretty strange.

Now you could make an argument that what iBooks is doing is not really multi-column layout but should instead be covered by overflow: paged-x, and so one possibility would be that we attack the problem there. I would definitely be open to that, although I would point out that iBooks in landscape mode shows two pages at once separated by a spine gap, and so that's one of the reasons why we use multi-column layout for the display of those pages.

Basically I just want to see a model for EPUBS where rotating your viewing device from landscape to portrait or swiping vertically vs. horizontally, etc., doesn't suddenly change the rules of pagination. If our ultimate goal is that EPUB-like content is intended to be displayed using overflow:paged-x/y instead of multi-column layout, then I suppose I'd be fine attacking the problem there. What I don't want to see, however, is content paginating wildly differently just because the content is paginated vertically instead of horizontally, or because you are displaying two pages on-screen instead of one.

Note there are also sites like onswipe that are producing paginated content of existing Web sites as well, e.g., for the iPad. Again this is a case of somebody else's content being turned into a multi-column layout.

dave
(hyatt@apple.com)