Re: [css3-page] Rules for Pagination into Varying-Width Pages

On Sep 19, 2011, at 12:14 PM, fantasai wrote:

> Rules:
> 
>  * Layout is performed per-page, with each page continuing progress from the
>    breakpoint on the previous page, but recalculating sizes assuming an initial
>    containing block of the current page size.

(1) Is the expectation that absolutely positioned objects could change widths and offsets as you cross pages? For example if you have a position:relative block with a width of auto (that thus fills the width of each page it is in), and you then place an absolutely positioned object inside that relatively positioned block with a left:20% and a width:50% will the positioned object have a different left offset and width on each page?

(2) If the answer to (1) is "Yes" how the heck does the "clip" property work when applied to such an object?

>  * Intrinsic sizes are calculated and maintained across the entire element. Where an
>    ICB size is needed, assume an initial containing block of the starting page's size.

(3) "starting page" needs to be defined. It's not clear to me what the "starting page" is for a positioned element. Are you essentially requiring that the top of an element be determined first before you can do anything else? I know in WebKit at least, we determine vertical extents and placement last, so this might be tricky. I just want to make sure that's your expectation.

(4) Percentage margins normally use the width of the containing block even if they are vertical. What vertical position do you expect to be used for margin top and margin bottom when considering what the "starting page" is for those margins? Given that margins collapse together, it seems very tricky to decide what page you're actually on for the purposes of computing a percentage vertical margin.

>  * Continuations of boxes on a previous page must start at the top of the page.
>    If this results in multiple shrinkwrapped floats side-by-side that would otherwise
>    be staggered (if they were not continuations), the floats' widths are reduced
>    in proportion to their original widths until they fit. However they are not
>    reduced past their min-content width; this may result in overlap between left and
>    right floats or side-by-side left floats overflowing the containing block.
> 

(5) Please don't include this rule, or just make it a suggested heuristic. I don't think it's necessary at all. If a sliced float gets pushed down on a later page, this is not a disaster.

> Implications:
> 
>  * Boxes (including tables) fullfilling layout constraints at their fill-available
>    size will change widths across pages.

(6) I'm not so sure I agree with this in all cases.  What about overflow:hidden/auto/scroll sections that are forced to split across pages?  It seems odd to me that you would allow the width of overflow sections to vary at all across pages. You may even have the scroll offset poked from JS, and then the whole object would be scrolled. I don't even know what you'd do if that object was allowed to vary in width. I see where you are coming from with e.g., tables and multi-column blocks and so on, but I think an exception should perhaps be made for overflow.

Either that or overflow should be defined as breaking up into multiple independently scrollable sections (also an option), but that has its own tricky implications (what does setting scrollTop from JS mean, etc.).

dave
(hyatt@apple.com)

Received on Saturday, 1 October 2011 03:31:32 UTC