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

On Oct 12, 2011, at 2:03 PM, Håkon Wium Lie wrote:

> Also sprach Brad Kemper:
> 
>>>> Paged Media currently always sends the block-axis overflow (or
>>>> vertical-axis, I dunno which) to the next page.  Inline (/horizontal)
>>>> overflow is hidden.  Presumably this should work the same.
>>> 
>>> Yes, it should work the same. But it should only be specified in one place. 
>> 
>> So, do we need an 'overflow-block-axis' that overrides 'overflow-x'
>> or 'overflow-y' depending on the block progression direction?
> 
> I don't understand what we would use it for. 
> 
> Opera's implementation is, in principle, quite simple. We reuse the
> multicol code and lay out the content of the element according to:
> 
>  http://www.w3.org/TR/css3-multicol/#pagination-and-overflow-outside-multicol
> 
> Now, if 'overflow: paged-*' is set (instead of 'overflow: visible' in
> the example), we create new pages from the overflow columns. These new
> pages are laid out according to the paged-* value. For example, if the
> language is RTL and 'overflow: paged-x' is set, pages are laid out
> leftwards. If 'overflow: paged-y' is set, pages are laid out downwards.
> 

I think that's a really weird way of thinking about pagination. You're effectively creating pagination slices along the inline axis instead of the block axis. I think that's pretty strange, and it isn't how columns in a document would lay out conceptually when printing them.

Imagine that I used this paged-x overflow value but didn't use columns. Now you've got this whole new pagination model to define (i.e., how do you paginate in the inline direction). This does not make much sense to me.

Basically it feels like you're trying to formalize a "hack", which is - to be fair - what we do in iBooks as well, which is create a horizontal strip using CSS multicol and then slide along it to show pages (either 1 column being shown or 2 columns being shown depending on orientation). However, in iBooks we've been hoping to move away from this model in favor of a better-defined pagination model that isn't built on columns but is built on pages instead.

> I don't see a need for a new property to achieve what I want. Am I
> missing something?


I think we should not be attempting to define pagination as ever happening along the inline axis of a box. I just don't think that is something we should be getting into, as it really only works in this case because you used multicolumn layout and so have a clear sense of where you can draw the pagination boundaries. For all other layout models, paginating along the inline axis is pretty bizarre.

I think pagination should always be along the block axis of a box, but that - for coordinate purposes - it would be acceptable to define how the pages are placed inside a box (even though you only see one at a time). For example it would be ok to say that the pages of a box are in a horizontal strip going from left to right even though you paginated along the block axis.

In other words, I think pagination should always be along the block axis, but that page placement could perhaps be controllable. Maybe that's what you really mean with this syntax?. It's certainly a valid interpretation to state that paged-x and paged-y are only about paged placement, and that once paginated you always paginate along the block axis (knowing that instead of putting columns in a strip, you'd break them up and move them to the next page).

Basically as long as you tell me that if no multicol is used that I still can paginate pages and have them placed in a horizontal strip using paged-x, but that the pagination happened along the block axis, then I think we're not too far off from one another. If you tell me that the inline overflow is what should be paginated, then we have a problem, since I think that makes no sense.

dave
(hyatt@apple.com)

Received on Wednesday, 12 October 2011 20:12:15 UTC