W3C home > Mailing lists > Public > www-style@w3.org > January 2009

[css21] [css3-page][css3-multicol] margins at page or column breaks

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,


Received on Wednesday, 14 January 2009 05:25:47 UTC

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