Re: [css3-gcpm] paged presentations, page floats, paged navigation between documents

On Oct 12, 2011, at 7:52 PM, Brad Kemper wrote:

> On Oct 12, 2011, at 3:12 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> 
>>> Just to follow up on this, another reason I think the page size
>>> should be independent of the size of the box is that in iBooks
>>> landscape mode we show two pages at once. Right now the fact that
>>> we happen to use a multi-column strip allows us to just show two
>>> "columns" since each "column" is in reality a page, but that just
>>> totally falls apart for writing modes like vertical-rl (where the
>>> column layout by default is in a vertical strip instead, but a 2-up
>>> display still needs to be a horizontal strip).
>> 
>> The 'paged-x' concept seems to match your requirement; it lays pages out
>> in horizontal strips no matter what writing direction is used in the pages.
> 
> 
> But by being a value for 'overflow', doesn't it override both 'overflow-x' and 'overflow-y'? So that whichever one is in the inline direction defaults back to 'visible'? 
> 
> Imagine a paged e-book about JavaScript or CSS that had some long lines of code that shouldn't be broken. I was imagining an author might want to do something like this:
> 
> overflow: auto /* takes care of x and y */; overflow-block-prog-dir: paged-inline-dir;
> 
> That way (ignoring for now how long it is too write), you could cause the extra pages to be arrayed in a strip in the inline progression direction, and have automatic scrollbars in the inline direction when an unbreakable line got too long. this also has good fallback. 
> 

I don't think that's a particularly desired user interface… especially considering that you want swiping gestures in the inline direction to flip through the pages. Having a scrollbar would muddle that, since swiping might then have to scroll you first before maybe flipping pages when you hit the scrolling boundaries of the page.

> 
> When i think about it, it seems like we don't need paged-x to create something similar to multi-col. If we have paging control UI (even like iBook's magic page flipping), then the other pages should hidden (like display: none), not laid out in a horizontal strip or inline-direction strip. 

Strip placement is relevant for a number of reasons. Apple has the requirement that we need to be able to show two pages at once in a horizontal strip. Second, unless we add new DOM API for jumping to specific pages etc., then authors are going to be doing coordinate math to move to specific pages (as well as doing things like word highlighting and Dictionary lookups for words, etc.).

I'd love to have real DOM API so that authors don't have to do this, but at least right now, authors have to be able to move around themselves.

One idea for how to solve the 2-up problem is just have additional overflow values, e.g., paged-2-x.

dave
(hyatt@apple.com)

Received on Thursday, 13 October 2011 16:16:43 UTC