CSS page-break-before/after:always Support

VERIFIED FIXED in mozilla1.0



Printing: Output
18 years ago
4 years ago


(Reporter: Andreas Steidle, Assigned: karnaze (gone))


({css2, testcase})

css2, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Hixie-PF][eapp]PATCH)


(3 attachments, 4 obsolete attachments)



18 years ago
I know you don't claim you've implemented CSS2, which is is ok. One
reason why PDF has become so popular on the web is that HTML has
ignored printing. For any serious documentation project that whishes
to use HTML and has to consider printing the page-break-* property is
*indispensible*, and should, IMHO, be among the first ones to be
considered when moving from CSS1 to CSS2.

I understand that some of the page-break-* values(!) might be somewhat
more difficult to implement, but a "page-break-before: always;" to
start a chapter on a new page is just like a the old form feed
and should be easy to do. Is it complicated to start a new pagebox?
Don't be surprised to see messages like "Your browser does not support
certain printing features. Please use Browser XY for proper formatting
on paper".


18 years ago
Target Milestone: M15

Comment 1

18 years ago
Not sure if this feature is implemented... or is going to be.
Will give to Pierre for disposition on this.. and if it is currently supported 
in Gecko ..   
Troy is doing the Pagination.
Assignee: dcone → pierre

Comment 2

18 years ago
It's in Style already. I don't know for Layout yet. Reassigned to Troy.
Assignee: pierre → troy

Comment 3

18 years ago
Marking as REMIND. Probably won't be implemented for version 1.0
Last Resolved: 18 years ago
Resolution: --- → REMIND
Pierre, if page-break-* is not going to be supported by layout, then the style 
system should probably not recognise the property at all, much as with 
the "display: marker", "content: counter()", and other such issues. I'm not 
sure if it matters so much with this property, however, since there is no 
difference between recognising it but not supporting any of it and ignoring it 
altogether, AFAICT.
Keywords: css2
OS: other → All
Hardware: Other → All

Comment 5

18 years ago
I don't think it matters with this property if the style sytem recognises it, 
and so Pierre can leave the support it. That way when layout does decide to 
support it we don't need to get Pierre to reenable it
reopen -> future
Resolution: REMIND → ---
er, -> Future!
Assignee: troy → dcone
Severity: normal → enhancement
QA Contact: shrir → sujay
Whiteboard: [Hixie-PF]
Target Milestone: M15 → Future
Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.
Keywords: nsbeta1
*** Bug 38164 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
Proposing for Mozilla1.0 as with the dup'd bug. This would be very useful to 
Keywords: mozilla1.0

Comment 12

17 years ago
Created attachment 38073 [details]
Testcase for page-break-after

Comment 13

17 years ago
The testcase that I just attached (based on code in bug 38164) correctly adds 
the page breaks with IE5. 

Comment 14

17 years ago
*** Bug 85279 has been marked as a duplicate of this bug. ***

Comment 15

17 years ago
I was wrong when I wrote on [2000-01-28 15:01] that page-break was in the style 
system already: it is parsed but it's not copied into the style context.

Marked dependency on bug 72321.
Depends on: 72321
Keywords: testcase

Comment 16

17 years ago
*** Bug 101960 has been marked as a duplicate of this bug. ***


17 years ago
Blocks: 104166
What would it take to get this implemented sooner than 1.0?  We have a customer
requirement for this, so I would be willing to work on it myself.

Comment 18

17 years ago
Thanks for the offer...

The changes in the style system are fairly easy: it's just an additional 
structure with the page breaks data (bug 72321 - I'll take care of it if you 
like).  Most of the work is in Layout: Don and Rod may give you more details.
*** Bug 110185 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
taking, I would love to do this one, just don't have the time now.
Assignee: dcone → rods


16 years ago
Whiteboard: [Hixie-PF] → [Hixie-PF][eapp]
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1+
Target Milestone: Future → ---

Comment 22

16 years ago
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1

Comment 23

16 years ago
I would love to fix this, but at the moment the CSS parser isn't even collecting
this information.


16 years ago
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1
This requires substantial work and really is a feature. We will not be able to
get to this for 1.0.
Marking nsbeta1-

Comment 25

16 years ago
Mozila is AFAIK the only browser with CSS2 support which does _not_ implement
this feature. Both Opera and IE>=5.5 supports this...

Comment 26

16 years ago
Just a little advocacy given the apparent support for Not Implementing Yet (or
worse, treating it as a feature.)
My own employer is switching over to web technology for a lot of the reporting
we give to customers. Before the web, we'd manually print the things having been
faxed a request to produce such-and-such a report, or, for our "online service",
used an Excel macro to populate a template worksheet with a CSV file.
Theoretically, we can now move to online kludge-free reports with HTML, but our
customers <i>do</i> want to print the things.
Well, what luck, they can! CSS2 gives us page-break-before, and Netscape 4.x
always tried to keep tables on one page, so we've written the code.
Along comes Mozilla. Compliant with web standards, DOM Inspectors and Javascript
debuggers, not to mention the other goodies be they "It's open source and
platform independent kinda" to "They have this funky tab thing. You should use
it, it's great." The entire programming team falls in love with it.
Except... except that in one critical area, it <i>isn't</i> compliant with web
standards. Well, it is in the "We said which standards we were going to
implement" way, but you know, and I know, and the submitter of the bug knows,
and the users know, and our PHBs know, that that's a cop-out. You can't have
useful printing without supporting page breaks. So the PHBs, who are having a
hard enough time being convinced of the argument for browser independence in the
first place, and who want to dictate exactly which browsers we use, are told
that all the programmers are developing {our online web product for dynamically
creating reports} using a browser that cannot even print our reports correctly,
not because it has a minor bug, not because we haven't used it's particular
workaround, but its implementation of CSS2 isn't as complete as Microsoft's is.
This "feature" is critical for serious business use of HTML and Mozilla. It's so
obviously a standard that <a
 ">DevEdge</a> lists it as best practice for DOM NS6 and IE!
If you can't implement it, could you at least look into some work-around, even a
non-standard &lt;break&gt; tag or something? Even implement the Netscape 4.x
tables hack? It might be ugly and might force us to put in some "if browser ==
mozilla" code, but right now, that would be an improvement.
Thanks, and whatever the rant above, let it be known that my collegues and I
really, really, appreciate what you're doing. Mozilla is a fantastic browser -
as I said above, it's the programmers' browser of choice where I work.


16 years ago
Priority: P3 → P2
Target Milestone: mozilla1.1 → Future

Comment 27

16 years ago
I'm taking the bug and will attach a patch shortly that uses rods' idea of 
creating dummy frames for page breaking. This will work for 
page-break-before:always and page-break-after:always. The other properties and 
values require much deeper layout changes that probably will not happen until 
long past m1.0.
Assignee: rods → karnaze

Comment 28

16 years ago
Created attachment 71320 [details] [diff] [review]
patch to temporarily implement page-break-before/after:always

This patch hasn't been tested much and there are a few things that still need
to be done besides further testing - (1) the logic of creating page break
frames in nsCSSFrameConstructor.cpp::ConstructFrame needs to copied to other
custom construction methods (e.g. ConstructTableFrame), (2) the style system
hacks should be removed and replaced with a new style struct; although if this
weren't done, I don't think the 2 added data members on nsCSSDisplay would be
that bad, assumming that nsCSSDisplay is not long lived like nsStyleDisplay.
Marking nsbeta1+ for supporting: 
page-break-before:always and 

Keywords: nsbeta1- → nsbeta1+


16 years ago
Target Milestone: Future → mozilla1.0

Comment 30

16 years ago
Just wanted to add my appreciation for you upping the priority on this issue,
it's definitely welcome!

Comment 31

16 years ago
Created attachment 73255 [details] [diff] [review]
revised patch

In this patch tables handle page breaks internally. There is still a problem
with the style system hacks and style context sharing.
Attachment #71320 - Attachment is obsolete: true

Comment 32

16 years ago
Created attachment 74229 [details]
test case with tables and divs

Comment 33

16 years ago
Created attachment 74243 [details] [diff] [review]
revised patch
Attachment #73255 - Attachment is obsolete: true


16 years ago
Whiteboard: [Hixie-PF][eapp] → [Hixie-PF][eapp]PATCH

Comment 34

16 years ago
Created attachment 74265 [details] [diff] [review]
revised patch with reviewer's suggestions

Revised to include some omissions caught by attinasi. This patch (as does the
previous one) also fixes the problems mentioned in comment #31, thanks to
Attachment #74243 - Attachment is obsolete: true

Comment 35

16 years ago
Comment on attachment 74265 [details] [diff] [review]
revised patch with reviewer's suggestions

r= alexsavulov

Comment 36

16 years ago
Comment on attachment 74265 [details] [diff] [review]
revised patch with reviewer's suggestions

I think that the eCSSProperty_page_break_inside cases should either be put in,
ore removed (commented at least) - there seems to be mixed attention given to
that property.

GetDesiredSize and Reflow should ASSERT/PRECONDITION aPresContent is non-null

What does 
+    // work around block bugs
mean in GetDesiredSize?

Shouldn't PageBreakFrame assert that we are in paged- mode (printing)?

Anyway, those are minor points - sr=attinasi
Attachment #74265 - Flags: superreview+

Comment 37

16 years ago
Created attachment 74442 [details] [diff] [review]
revised patch with additional reviewer's suggestions

Encorporates all of attinasi's suggestions except the 1st one, which he agrees
is ok to ommit.
Attachment #74265 - Attachment is obsolete: true


16 years ago
Attachment #74442 - Flags: superreview+
Attachment #74442 - Flags: review+

Comment 38

16 years ago
Comment on attachment 74442 [details] [diff] [review]
revised patch with additional reviewer's suggestions

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74442 - Flags: approval+
temp fix for bug 2400

Could we please fix that comment to have the right bug number?

Comment 40

16 years ago
The patch is in. I'll fix the comment.
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 41

16 years ago
Suggested change:
s/temp fix for bug 2400/temp fix for bug 24000 ("CSS page-break-* Support ?")/

Comment 42

16 years ago
Is this fixed for all page-break-* properties now, or is there a bug to track
the real fix (post 1.0)?

Comment 43

16 years ago
Changing summary to restrict to page-break-before/after:always. Someone can open 
a new bug for full page break support, but it will probably not be fixed for a 
long time.
Summary: CSS page-break-* Support ? → CSS page-break-before/after:always Support

Comment 44

16 years ago
I've opened bug 132035 for support of all CSS2 page-break-* properties.

Comment 45

16 years ago
Can anyone file a bug to get some tests into the printing tests used for the
smoketesting ?

Comment 46

16 years ago
Andreas this is fixed now..can you verify this in latest build ?

thanks...let me know if this is working for you now...

Comment 47

16 years ago
verified...REOPEN if still not fixed...h


15 years ago
Depends on: 202927
You need to log in before you can comment on or make changes to this bug.