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

On Sep 30, 2011, at 10:29 PM, David Hyatt wrote:

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

Just to include my own opinions here along with the questions, I would suggest;

(1) Yes, positioned objects can change widths and offsets as you cross pages.

(2) clip would be re-applied on each page to the hypothetical full border box that you would get if you expanded the portion in that page to the full height of the element.

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

(3) Yes, you are requiring that top be computed first. Another point is that top/right/bottom/left when your containing block is the page would still use the ICB (i.e., the first page).

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

(4) I'd suggest you use the bottom of the border box of the last content prior to any margins when computing bottom/top margins. I'm sure there are many more details to work out, but that seems to be a good starting point.

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

(5) I think this rule should be left out, since there are other constructs besides floats that can be pushed down and not sit at the top of a page. A good example is any block that shrinks to avoid floats but has a certain minimum content width that is exceeded in a following narrower page. In that case the object's continuation would be shoved down below those floats. Or, if you disagree, you need to enhance your rule to indicate that floats will try to shrink to accommodate other non-floating continuations that fit to the available line width.

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

(6) I really don't know what to do with overflow, especially if you have a scrolling mechanism. If you do apply your rule and have the object potentially able to have different widths/placement in each page, then you have distinct overflow clip regions in each page. It's obvious how to apply that clip (see what I mentioned in (2) above), but scrolling becomes extremely problematic. Where do scrollbars display?

Content in a narrower page may be clipped and cause you to need scrolling, but then in a following page, the content might all fit. I am thinking we should apply your rule and allow overflow sections to vary width/placement in each page, but recommend that scrolling mechanisms are suppressed and disabled when an overflow object is forced to paginate. This situation really only occurs in degenerate cases anyway, since you'd obviously treat a scrollable section as unsplittable and try to keep it on the same page by default. You'd only split across pages if no page was tall enough to accommodate the entire block.

dave
(hyatt@apple.com)

Received on Sunday, 2 October 2011 02:57:12 UTC