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

On Oct 13, 2011, at 9:05 AM, David Hyatt wrote:

> 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.

Yes, well, hopefully there wouldn't be scroll bars on every page, or maybe swiping from the corner would always turn the page even if there was horizontal overflow or something. Are you suggesting that you prefer a model where if paging is used then all overflow in the inline direction would be clipped? I think I'd rather that be the default, but still allow for other overflow values. You still allow them in child elements, no? And they would have the same problem with swiping?

>> 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.

So, supposing you currently have a multi-col element for each chapter (pretty interesting, BTW; I love iBooks on my iPad, and never realized it worked that way). If you converted them to a new "multi-page" element, couldn't each "page" just switch to two columns when the ipad is rotated to horizontal? So, chapter = multi-page, and each page = multi-col.

> 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

I assumed that bookmarks and tables of contents would use standard hyper links. It does seem pretty essential to have an API to jump to a specific page too. I don't understand how how having the pages arrayed side-by-side would help in situations where the width of each "page" might not be known (not the iPad/iPhone problem, but perhaps more so on the Web or on Android).

> (as well as doing things like word highlighting and Dictionary lookups for words, etc.).

I don't understand that. Can you explain how it helps with that?

> 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.

So it sounds like you think on-screen pages will be standardized long before any API is developed? It sounds like we do need an API, and should develop it concurrently.

Received on Thursday, 13 October 2011 17:18:42 UTC