24000 - CSS page-break-before/after:always Support

Status: VERIFIED FIXED

(Core :: Printing: Output, enhancement, P2)

Description

[Andreas Steidle]

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".

Comment 1

[dcone (gone)]

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.

Comment 2

[Pierre Saslawsky]

It's in Style already. I don't know for Layout yet. Reassigned to Troy.

Comment 3

[troy]

Marking as REMIND. Probably won't be implemented for version 1.0

Comment 4

[Hixie (not reading bugmail)]

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.

Comment 5

[troy]

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

Comment 6

[Hixie (not reading bugmail)]

reopen -> future

Comment 7

[Hixie (not reading bugmail)]

er, -> Future!

Comment 8

[Hixie (not reading bugmail)]

Nominating this bug for nsbeta1 on behalf of [e-mail].

Comment 9

[Boris Zbarsky [:bzbarsky]]

This is identical to bug 38164

Comment 10

[Hixie (not reading bugmail)]

*** Bug 38164 has been marked as a duplicate of this bug. ***

Comment 11

[Tim Powell]

Proposing for Mozilla1.0 as with the dup'd bug. This would be very useful to 
have.

Comment 12

[Tim Powell]

Attachment: Testcase for page-break-after

Comment 13

[Tim Powell]

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

Comment 14

[Mike Young]

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

Comment 15

[Pierre Saslawsky]

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.

Comment 16

[James Lariviere]

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

Comment 17

[jhp (no longer active)]

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

[Pierre Saslawsky]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 110185 has been marked as a duplicate of this bug. ***

Comment 20

[rods (gone)]

taking, I would love to do this one, just don't have the time now.

Comment 21

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 22

[Bob Clary [:bc] (inactive)]

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.

Comment 23

[rods (gone)]

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

Comment 24

[Kevin McCluskey (gone)]

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

[Roland Mainz]

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

[Paul Harrison]

Just a little advocacy given the apparent support for Not Implementing Yet (or
worse, treating it as a feature.)
<p>
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.
<p>
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.
<p>
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.
<p>
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.
<p>
This "feature" is critical for serious business use of HTML and Mozilla. It's so
obviously a standard that <a
href="http://developer.netscape.com/evangelism/docs/technotes/xref/dom-css-style-object/
 ">DevEdge</a> lists it as best practice for DOM NS6 and IE!
<p>
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.
<p>
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.

Comment 27

[karnaze (gone)]

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.

Comment 28

[karnaze (gone)]

Attachment: 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.

Comment 29

[Kevin McCluskey (gone)]

Marking nsbeta1+ for supporting: 
page-break-before:always and 
page-break-after:always

Comment 30

[Paul Harrison]

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

Comment 31

[karnaze (gone)]

Attachment: revised patch

In this patch tables handle page breaks internally. There is still a problem
with the style system hacks and style context sharing.

Comment 32

[karnaze (gone)]

Attachment: test case with tables and divs

Comment 33

[karnaze (gone)]

Attachment: revised patch

Comment 34

[karnaze (gone)]

Attachment: 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
attinasi.

Comment 35

[Alexandru Savulov]

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

r= alexsavulov

Comment 36

[Marc Attinasi]

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

Comment 37

[karnaze (gone)]

Attachment: revised patch with additional reviewer's suggestions

Encorporates all of attinasi's suggestions except the 1st one, which he agrees
is ok to ommit.

Comment 38

[Asa Dotzler [:asa]]

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

Comment 39

[Boris Zbarsky [:bzbarsky]]

+  CHECKDATA_PROP(nsCSSDisplay, mBreakBefore, CHECKDATA_VALUE, PR_FALSE), //
temp fix for bug 2400

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

Comment 40

[karnaze (gone)]

The patch is in. I'll fix the comment.

Comment 41

[Roland Mainz]

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

Comment 42

[Christopher Whitt]

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

Comment 43

[karnaze (gone)]

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.

Comment 44

[Steve Chapel]

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

Comment 45

[Roland Mainz]

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

Comment 46

[sujay]

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

[sujay]

verified...REOPEN if still not fixed...h