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

On Oct 20, 2011, at 1:36 PM, Alex Mogilevsky wrote:

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

I've implemented this in WebKit now, and the rules that I came up with are basically:

(1) "auto" positions obviously evaluate based off where you are. No-brainer.
(2) Explicit top and bottom values use the first region as the ICB if your containing block is the whole flow thread, assuming the flow thread is a horizontal writing mode. Otherwise left and right values use the first region as the ICB.
(3) Explicit left and right values can vary from region to region, so you compute per region (e.g., left:20%) rather than using the first region as the ICB. For vertical writing modes, top and bottom vary from region to region.

> 
> ± >>> * 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…
> 

Ok, if we keep it, we just need to make sure it's expanded to cover all cases, since overflow sections that shrink to avoid floats have the same issues floats do.

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

I more or less implemented what fantasai suggested. overflow:hidden that doesn't have a resolved explicit height paginates normally. Otherwise we'll try to keep it all together on the same page.

dave

Received on Thursday, 20 October 2011 18:58:22 UTC