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

I agree on most points, a few comments below

± From: fantasai
± Sent: Wednesday, October 19, 2011 12:59 PM
± 
± On 10/01/2011 07:55 PM, David Hyatt wrote:
± > (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.
± 
± I think I agree with your suggestions here. :)

Alex agrees too.

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

I am not so sure about it. ICB size (or containing block size) is needed for percent sizing of positioned elements, right? In normal layout, positioned elements are sized to whatever their containing block is, then positioned, possibly to locations far away.

Why not use the page of positioned element's static position? That would make "top:auto" work as expected, and other cases predictable.

Are there use cases for percent-size positioned elements placed to a different page?

± > 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).
± 
± For abspos elements without a positioned ancestor? Yes, I would think so, given we 
± use only the viewport for scrolled media.

Sounds right

± >> (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.
± 
± Margins are truncated at page breaks, so I don't see the problem here: the entire 
± collapsed margin will be restricted to a single page. No?

Agree

± >>> * Continuations of boxes on a previous page must start at the top of the page.
± 
± >> (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
±  
± I think I'm ok to leave it out unless we find problems with it further down the road.

I actually prefer Fantasai's rule. Cases where post-break content collides due to page width change can't possibly be common. There is no universally good solution here, but having a solid rule that whatever I was just reading at previous page will continue on top of next page has a value. I would prefer that over content being put elsewhere (possibly many pages down), even if content overlaps. After all, this is dealing with bad design...

± >> 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.).
± 
± overflow: hidden; should be treated just like overflow: visible, except it will clip 
± to the padding-box. Most people think of it as a way to clip content, not as a way of 
± creating a scroll box without scroll bars.

Almost. You mean "like overflow:visible, and there are no page breaks in overflow", right?

± > (6) I really don't know what to do with overflow, especially if you have a 
± scrolling mechanism. 
± 
± I think the most sensible thing to do with scrollboxes would be to treat them similar 
± to a replaced object: you just do a graphical slice at the pagination point.

We print boxes with scrollbars, paginated across pages. It is not uncommon to have a large scrollable box on a page that wasn't designed to print, but you still want to print it for your records. If you push the whole scrollbox to next page you won't see any more of the text on paper, but it will likely ruin overall shape of layout.

Pagination in interactive mode (regions) is a very different story. It totally makes sense to keep scroller intact. Pagination rules needs to recognize that pagination decisions can depend on media (or possibly other triggers that favor layout closer to paper).

Alex

Received on Thursday, 20 October 2011 18:37:28 UTC