W3C home > Mailing lists > Public > www-style@w3.org > October 2011

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Thu, 20 Oct 2011 18:36:56 +0000
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "David Hyatt (hyatt@apple.com)" <hyatt@apple.com>, "Rossen Atanassov" <Rossen.Atanassov@microsoft.com>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928412D15785@TK5EX14MBXC214.redmond.corp.microsoft.com>
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.

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?


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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:51 UTC