- From: Grant, Melinda <melinda.grant@hp.com>
- Date: Mon, 3 Nov 2008 21:30:21 +0000
- To: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <763AE400FE923441B74861D534DF254955B168FD11@GVW0433EXB.americas.hpqcorp.net>
Hi Alex, Comments intercalated below. Best wishes, Melinda ________________________________ From: Alex Mogilevsky [mailto:alexmog@microsoft.com] Sent: Sunday, October 26, 2008 3:35 AM To: Grant, Melinda; www-style@w3.org Subject: FW: [css3-page] Page area changes within a document I agree with the intent of concept of element adapting to page size change. The primary scenario as I understand it looks like this: table { page: landscape; } at this point, if no other sizing properties are involved, the table’s available width should be the page width. The rule that an element going across pages, should adapt to changing width is one way to assure that. [MG] I don't think named pages, such as the example you provide, are really the issue at hand: they generate a (conditional) page break before and after, to ensure that you *don't* need to worry about flowing content across discontinuities. The cases we're concerned with here are brought about by :first, :right, and :left variations on a particular page-name theme. Page foo:right can have a very different page area than foo:left for simple reasons like differing margins or borders, and a page break is likely to occur mid-element, so there's no explicit page break between elements to keep things simple. If an element “adapts” to page change, I believe it means this: · Page box changes – background, border, shadow · For descendant elements, parent size and position depends on what page the child element is at (which could be the page at which element starts, the page currently calculated, or perhaps the page of element’s static position) · Text content reflows into current page width, including positioning of floats and absolute-positioned content that continues from previous page(s). I am sure it is possible to produce a complete set of layout algorithms that produce good results with all these constraints, but I think we should be very careful about mandating details until there is a solid implementation (ideally including other complex page properties, as page floats, columns, footnotes). [MG] Yes. For the sake of making progress, I would be fine with a recommendation that makes known use cases work, at a “should” level rather than “must” – which is I believe what we resolved at f2f [MG] I think this is a really good answer, not just to this particular issue, but as a more general approach to addressing the paged media questions flapping in the breeze that we haven't been ready to pin down and mandate. (E.g., when a page break splits a box with a background, is the background propagated to the end of the page area? When a block begins a new page, should its top (start?) margin collapse with the adjacent page margin in the absence of intervening padding and border?) It would be great if we can begin to build consensus on how they "should" behave. Alex
Received on Monday, 3 November 2008 21:32:06 UTC