- From: Grant, Melinda <melinda.grant@hp.com>
- Date: Wed, 14 Jan 2009 05:23:07 +0000
- To: Michael Day <mikeday@yeslogic.com>
- CC: H�kon Wium Lie <howcome@opera.com>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <763AE400FE923441B74861D534DF2549585EFC4519@GVW0433EXB.americas.hpqcorp.net>
(Adding 2.1 to the subject...) Michael said: > > Melinda said: > >> H�kon said: > >> > Murata-san said: > >> > 2. Margins at forced page breaks will be set to zero? > >> > >> According to the spec, yes. (But I vaguely recall > discussing this and > >> reaching a different answer? Melinda? It could be argued > that pages > >> after forced page breaks should be treated like the first page.) > > > > Yes, we've struggled with this. I don't think either > answer fits all > > scenarios, so I think we'll need a control here, as XSL-FO > has done. > > We have pretty strong interop for 2.1, so I don't think we want to > > change this now. (Arguments to the contrary, Michael?) > > We currently respect vertical margins on the first page and > after user-requested page breaks, eg. page-break-after: > always, or use of named pages. This avoids the scenario of > specifying a top margin on a chapter heading with absolutely > no effect, which can be baffling. > > Vertical margins at involuntary page breaks are set to zero. > > Block margins are collapsed with page margins, assuming that > the page has no border or margin content. Hmmm, I especially agree with your rationale for retaining the margin-top after a forced page break. (Not only to avoid baffling people, but also because a designer *ought* to be able to get their chapter headers after forced page breaks to be positioned equivalently without doing 'exception' styling for the first page...) Unfortunately, the 2.1 spec doesn't currently allow this. I think it should. And I think we should mandate that behavior for css3-page. I also think it's pretty obviously true that we should retain the margin-top for the first of a sequence of named pages, so I'll add that to css3-page, too. Collapsing margin-top with the page margin is something else we've struggled with; one model is that these margins should be collapsed when they abut (as Prince does) and the other is that they're the equivalent of 'chrome' for screen and so they shouldn't collapse. I think we should allow either behavior for 2.1 and lock it down for css3. Right now we have at least three implementations that don't collapse and, so far as I know, only Prince that does; unless use cases favor collapsing, I'd prefer to land on not collapsing the page margin with other margins. [I tested IE8, FF3.0.5, Opera9.6.3, Chrome1.0.154.43, Prince6.0r7, HP latest, and Epson Artisan 800 (one test attached) and obtained the following results: Opera FF Chrome IE Prince HP Epson ----------------------------------------------------- Retains margin at top of first page yes yes yes yes yes yes yes Retains margin after forced break no no yes no yes no no No margin-top after unforced break between line boxes yes yes no yes yes yes yes Zeros margin-top after unforced break between block boxes yes no yes yes yes yes yes Collapses margin-top w/ pg margin no x x x yes no no Retains margin at top of first named page x x x x yes no no (the x's indicate lack of support for the feature under test.) ] Best wishes, Melinda
Attachments
- text/html attachment: page-break-margins.htm
Received on Wednesday, 14 January 2009 05:25:47 UTC