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

On Oct 13, 2011, at 12:18 PM, Brad Kemper wrote:

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

Well, the way I think of this is that the box is applying a clip to its padding area because of the overflow value. You then have some possibly inset page (e.g., maybe @page gives you some margins). I would not expect any inline overflow off the page itself to be reachable, since I think the use cases for this feature will be carefully crafted content that is designed to look good when paginated.


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

Sure, they would (unless you use a different gesture of course).

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

That doesn't work in the vertical-rl case. For vertical-rl where you show two pages at once, they need to be next to each other horizontally. Imagine that you're looking at the first two pages of the book. Page 1 is on the right and flows into Page 2 on the left. They are connected horizontally.

However, multi-column can't be used to implement that, since when you actually use multi-column layout in a Japanese book, the columns are stacked vertically. This is something iBooks actually can't handle right now as a result of the choice to use multi-column as the implementation.

This is why I agree with Hakon's idea that you should be able to state how the pages are stacked (either in the horizontal or vertical direction).

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

If you assume that the overflow section's padding area establishes the sizing box, then you would always know the size of the page. As Hakon alluded to in a previous post, if the overflow section is not constrained, then you just wouldn't paginate.

>> (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?
> 

Dictionary is an external app that is plugging in, so it needs to know where to show its window. It comes up right underneath a highlighted word, so it needs to know where that word is in the view.

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

Yeah, I very much think a pagination mode should have an API. Just as we didn't expect <video> authors to be satisfied with the built-in controls, we can't expect people developing paginated applications to be content with built-in controls either. That means providing sufficient scripting APIs that the authors can roll their own controls.

dave
(hyatt@apple.com)

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