Last Comment Bug 132035 - Implement missing page-break-* CSS2.1 features
: Implement missing page-break-* CSS2.1 features
Status: NEW
[useful information in comments 0, 54...
: css2, dev-doc-needed, testcase
Product: Core
Classification: Components
Component: Layout: Misc Code (show other bugs)
: Trunk
: All All
: P3 normal with 231 votes (vote)
: Future
Assigned To: fantasai
:
:
Mentors:
https://drafts.csswg.org/css-break-3/...
: 195401 198513 210643 216972 217144 239137 278251 308970 322393 330132 332531 346918 403836 429476 445212 580312 655634 877383 (view as bug list)
Depends on: 136714 326685 683043 775617 1109275 page-break-inside
Blocks: 137367 171549 217145 521204 549114 css2.1-tests css3-break 495580 616342
  Show dependency treegraph
 
Reported: 2002-03-19 08:30 PST by Steve Chapel
Modified: 2016-03-15 03:51 PDT (History)
143 users (show)
roc: blocking1.9.2-
roc: wanted1.9.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase for verification (16.78 KB, text/html)
2003-04-08 00:45 PDT, Daniel Wang
no flags Details
Another Test Case - Demonstrates failure with page-break-inside: avoid (205 bytes, text/plain)
2005-05-04 14:01 PDT, Kevin Benton
no flags Details
Screenshot of print preview showing a page-break-inside: avoid failure (12.48 KB, image/png)
2006-01-10 00:38 PST, Gérard Talbot
no flags Details
Testcase #1, <p>'s with page-break-before:avoid (969 bytes, text/html)
2006-05-11 05:47 PDT, osakawebbie
no flags Details
Testcase #2, <div> with page-break-inside: avoid (1014 bytes, text/html)
2006-05-11 05:54 PDT, osakawebbie
no flags Details
Page-break-after:avoid testcase (11.44 KB, text/html)
2007-03-16 06:17 PDT, mikhail
no flags Details
Can do divs, paragraphs, simple tables and columns (some part of table is still broken) (24.19 KB, patch)
2011-09-04 22:23 PDT, Chris
fantasai.bugs: review-
Details | Diff | Splinter Review
proposed testsuite (to be converted to reftests) (720.88 KB, application/x-7z-compressed)
2011-09-04 22:32 PDT, Chris
no flags Details

Description Steve Chapel 2002-03-19 08:30:21 PST
With the fix for bug 24000, Mozilla now supports the page-break-before:always
and page-break-after:always CSS2 styles. This bug is for support of
page-break-inside and the avoid, left, right, and inherit values for
page-break-before and -after.
Comment 1 rods (gone) 2002-03-19 11:12:03 PST
chris, you asked for it :)
Comment 2 jr 2002-05-02 19:53:32 PDT
As of Mozilla RC1. Page breaks do not work (at least in Print Preview)
Comment 3 karnaze (gone) 2002-05-05 13:59:11 PDT
Page breaks use to work partially (at least the ones in bug 2400). Are you 
saying that no page breaks work any longer?
Comment 4 jr 2002-05-05 15:01:18 PDT
mozilla rc1 doesn't respond to the CSS2 properties: page-break-before &
page-break-after

I've never actually tried printing a page, just print preview.
Comment 5 Kai Lahmann (is there, where MNG is) 2002-05-05 15:17:15 PDT
jr, does it work there for you):

http://selfhtml.teamone.de/css/eigenschaften/anzeige/page_break_before.htm

(it does for me in 2002050107 on Linux)
Comment 6 jr 2002-05-06 09:33:30 PDT
Yes that page does work for page breaks in RC1 - WinXP . I am going to try and
pull up an example page that I was trying to work with before and parse it with
the W3 and make sure it is valid, then if it still doesn't work I'll post it on
here.
Comment 7 madeleine mcjones 2002-06-21 16:31:15 PDT
Please help me help me and my clients to use NS7.0
Why in Netscape 7.0 does the below code not work,
with or with out the doctype (strict/quirk)
When you print/preview the page you do not get the page break -
(Please note this example/URL is not really my code but it has the same
problem.)

I need a page break in a report!  I am stumped...I would like to do
something else today...if anyone can save me hours more time spinning on
this I would be very jolly!

Madeleine

EXAMPLE:
---------------------------
<!DOCTYPE HTML>
<HTML>
<HEAD>
<TITLE></TITLE>
<STYLE TYPE="text/css"><!--
HR { page-break-before:always; }
--></STYLE>
</HEAD>
<BODY BGCOLOR="white">
page-break-before‚ðŽw’肵‚Ä‚Ý‚Ü‚µ‚½?B
<HR>
HRƒ^ƒO‚²‚Ƃɉüƒy?[ƒW‚É‚È‚é‚Í‚¸‚Å‚·?B
<HR>
‚±‚̃y?[ƒW‚Í‚Rƒy?[ƒW‚Æ‚È‚Á‚Ĉó?ü‚³‚ê‚é?E?E?E‚Í‚¸‚Å‚·(^^;
</BODY>
</HTML>
-------------------------------

GO HERE TO TEST IT

http://www.openspc2.org/CD-ROM/imasugu3/cd-rom/css/page-break-before/sample.html



Comment 8 Garth Wallace 2002-06-23 16:05:45 PDT
madeline: Bugzilla is for reporting bugs in Mozilla. It is not a tech support
forum. Try the netscape.mozilla.users.* groups on secnews.netscape.com (secure
mode).
Comment 9 madeleine mcjones 2002-06-24 12:23:16 PDT
Thanks Garth, But that is who snubbed me and pointed me to this location!  I 
really did not mean to ask for help on a bug that needs fixed, I was just being 
lazy from spending all day on this and I am guilty of cutting and pasting the 
whole issue from past emails to those newsgroups to here.  I was really 
submitting an EXAMPLE/testcase perhaps? and trying to be include on the updates 
on its fix? I thought that -this- where you do -that-.  I know I am not 
anybody-big-mozilla programmer and that I do not know anyone important and I 
guess that is what it takes to get included on any help these days... on 
newsgroups or here. I will remove my little self with my little page break 
problem. I told the users to stay with IE until I "notice" it is fixed in 
Mozilla and transitined to NS. Or perhaps I will glance back here time to time? 
In my spare time,ha, perhaps not. Sorry. Bye. Madeleine.
Comment 10 Greg Jarmiolowski 2002-07-19 08:16:03 PDT
I have tested this in Mozilla 1.0 on Windows 98. page-break-before only works
when defined as a style attribute for the tag or when defined as a CSS rule for
a tag. If you create a class rule and apply it to a tag it ignores it.
Comment 11 karnaze (gone) 2002-07-19 08:33:32 PDT
The patch in bug 2400 put some hacks in the style system and probably overlooked 
class rules. We need to remove those hacks and support page breaking in the 
style system before fixing this bug.
Comment 12 Mark Swaffer 2002-09-17 20:03:58 PDT
I've inserted the following to my document to avoid having my tables split
between pages:

<style type="text/css" media="print">

     table {page-break-inside: avoid}
  </style> 

W3 says that this is valid CSS, so assuming that this should be producing what I
expect, which is to not have my tables broken, then I am witnessing this bug as
my tables still are being broken up (at least in the print preview).

As a bit of a side note, I was reading up on the usage of CSS and that, and from
what I gathered (which could be incorrect as this stuff is mostly over my head)
the browser shouldn't be breaking tables to begin with, so no additional code
should be needed to prevent that. Is this another bug or am I making incorrect
assumptions?

Anyway, I will vote for this bug.
Comment 13 Matthew S 2002-09-17 22:36:34 PDT
"As a bit of a side note, I was reading up on the usage of CSS and that, and
from what I gathered (which could be incorrect as this stuff is mostly over my
head) the browser shouldn't be breaking tables to begin with, so no additional
code should be needed to prevent that. Is this another bug or am I making
incorrect assumptions?"

The difference you need to understand is between screen media (normal web view)
and paged media (i.e. paper).  On your computer screen, tables are never broken
because there's no need to do so, as the media is never broken. On a monitor, an
entire web page is shown as one "page" that you can scroll thru.  On the other
hand, paper has an unavoidable gap every so often that you have to deal with. 
As for never breaking tables to begin with: For a table that is longer than a
page of paper, there's no way to get away without breaking it.  The "avoid"
directive just lets you say "don't break unless you really have to".
Comment 14 Eric A. Meyer (dead account) 2002-09-18 08:30:51 PDT
Right, it's impossible to guarantee that an element will never have a page break
inside itself-- what if the user's print setup is configured to only provide a
printing area three lines of text high?  An extreme case but still one the
browser has to worry about.  The real question is whether Gecko is doing enough
to avoid page-breaks inside elements that have been set to 'page-break-inside:
avoid'.  I don't know the answer, but it's something that would have to be
examined once work gets underway to fix the problems mentioned in comment 11,
for example.
Comment 15 Mark Swaffer 2002-09-18 13:29:24 PDT
I understand the differences between paged media and screen media. What I'm
seeing is my tables, which are nowhere near the size of the printable area of
the page, being split right at the bottom margin of the page instead of moving
the whole table to the next page to avoid splitting the table. Its even
splitting single cells if they fall along that border, rather than preserving
the entire cell. Near as I can see, Gecko is doing nothing to avoid breaking up
a table even when set to 'page-break-inside: avoid'.
Comment 16 Matthew S 2002-09-18 14:45:57 PDT
Right.  That's this bug.
Comment 17 Garth Dahlstrom 2002-10-23 11:40:45 PDT
My captions are split off my images when the space left on the page won't 
fit the image.  Moz is ignoring all of the avoids even for page-break-before
and page-break-after... :(

Here is a bit of the doc... there is text before this that makes it so
the image will not fit in the space left at the bottom of the page.

<style type="text/css">
<!-- 
  .figure {  page-break-inside: avoid;  }
  .figurecaption { page-break-after: avoid; } 
  img { page-break-before: avoid; }
-->
</style>

... text here ...

<div class="figure"><div class="figurecaption">
<I>Figure 1-3: <A NAME="77006"></A></I><I>ChatZilla, an IRC chat 
client created by using Mozilla</I></div><img
src="http://books.mozdev.org/screenshots/moz_0103.gif" alt="Figure 1-3"></div>
Comment 18 Casper Hulshof 2002-12-13 04:58:48 PST
In general, what is the status of CCS2-support? I haven't found a meta-bug that
is associated with this.

Re comment 12: I've also used page-break-inside, and have tried it in a number
of browsers. So far, only Opera (version 7) does the correct job. My solution:
open your file (with tables) in Word and print it. You can configure Word not to
break table cells.
Comment 19 karnaze (gone) 2003-03-31 11:02:05 PST
mass reassign to default owner
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2003-04-07 23:55:01 PDT
Hmm... Over to misc layout code, for now....  That seems like the best place.
Comment 21 Daniel Wang 2003-04-08 00:45:37 PDT
Created attachment 119787 [details]
testcase for verification
Comment 22 Bill Mason 2003-08-22 01:37:09 PDT
*** Bug 216972 has been marked as a duplicate of this bug. ***
Comment 23 Bill Mason 2003-08-22 01:38:22 PDT
*** Bug 195401 has been marked as a duplicate of this bug. ***
Comment 24 Jo Hermans 2003-08-24 23:52:50 PDT
*** Bug 217144 has been marked as a duplicate of this bug. ***
Comment 25 dolphinling 2003-10-12 13:12:04 PDT
*** Bug 217145 has been marked as a duplicate of this bug. ***
Comment 26 Dave Yost 2004-01-14 23:54:19 PST
The 'testcase for verification' does not test the CSS2 recommendation that tables implicitly act as if 
they have page-break-inside:avoid.  See <a href="http://Yost.com/computers/html-printing-
problems">http://Yost.com/computers/html-printing-problems</a>
Comment 27 Dave Yost 2004-01-15 00:01:14 PST
Could this bug please be split into two?

  Bug 1:
  Getting tables to act as if they have "page-break-inside: avoid".
  
  Bug 2:
  Everything else from this bug.

I say this hoping that #1 would be easier to implement than 1 + 2, and that #1 could therefore be 
expedited.
Comment 28 Nicolas Mailhot 2004-02-20 02:38:25 PST
I have a page with lots of screenshots here.
Moz printing is terrible - almost all shots have a page break inside.

Usinsing page-break: avoid does not work

(it *did* cure printing in ie)

So it's not even about opera parity anymore - moz is even not at ie CSS level here.
Comment 29 Dave Yost 2004-02-24 09:08:43 PST
A previous comment claims that using 'page-break: avoid' works in IE.  I cannot reproduce this using 
the 
page at http://Yost.com/computers/html-printing-problems/ with print preview in IE on Winows 2000, 
updated with latest updates.
Comment 30 Nicolas Mailhot 2004-02-24 13:28:10 PST
I won't claim it works always. Just that it worked in my case. I don't know if
IE support is full or only works one time out of X (as usual)

BTW I made a typo, it was page-break-inside: avoid but I thought everyone would
correct it without me admitting I botched my comment;) Sorry
Comment 31 vectro 2004-04-21 22:27:27 PDT
Using IE 6.0.2800.1106CO for Windows 98, and using the following CSS:

P { page-break-inside: avoid;
    text-indent: 5ex; }

I find that not only are my paragraphs broken up in the middle, but that IE
inserts a new paragraph indent on the second page!

Mozilla is definately in the lead on this one.
Comment 32 Gérard Talbot 2004-09-21 18:43:31 PDT
*** Bug 239137 has been marked as a duplicate of this bug. ***
Comment 33 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-01 14:39:02 PST
*** Bug 210643 has been marked as a duplicate of this bug. ***
Comment 34 Anne (:annevk) 2005-01-13 10:01:22 PST
*** Bug 278251 has been marked as a duplicate of this bug. ***
Comment 35 Daniel Kraft 2005-02-20 00:26:08 PST
As I use XHTML often for documents which I also have to print, I'd really
welcome it to see this fixed (inserting all page-breaks manually as needed costs
a lot of time and is unnecessary, as we have computers, isn't it?).
I think it shouldn't be that difficult to implement the left and right values
(as they are similiar to always, which already works).
Also page-break-inside: avoid; is useful and should be not too hard (see if the
element fits on the rest of the page, if not, do as if page-break-before:
always; That's it, as far as I can see).

I want to try to do this, but currently I don't have much knowledge about how
paging works in Mozilla. Can anyone give me some hints where to look at? And
what really needs to be done and what's already implemented (e. g. for the style
system)?
Comment 36 Jonathan Abbey 2005-03-27 00:17:09 PST
It was implied earlier in this bug that perhaps some of the page-break CSS2
properties might work if the style information was included in the element tag
rather than in a class styling.

This isn't the case with latest FireFox, "page-break-inside: avoid;" doesn't
work for images at all, from what I can see.

This does work on my print tests with IE 6 XP SP 2.
Comment 37 Anne (:annevk) 2005-03-27 00:23:34 PST
Please don't add comments to the bug unless you are planning to fix it and have
a patch ready.
Comment 38 Dave Yost 2005-04-28 15:47:42 PDT
A friend writes:
Your printing problem is universal, but I circumvent it by nursing an old
version of Communicator (4.7), which installs from cc32e47.exe (20MB). I tried
it on your test page, and it printed all right.
Comment 39 Kevin Benton 2005-05-04 14:01:19 PDT
Created attachment 182615 [details]
Another Test Case - Demonstrates failure with page-break-inside: avoid

Sorry folks, but this works with Internet Exploder.
Comment 40 Uri Bernstein (Google) 2005-09-17 11:05:33 PDT
*** Bug 308970 has been marked as a duplicate of this bug. ***
Comment 41 David E. Ross 2005-09-18 15:33:48 PDT
Since the Summary reads "Support ALL page-break-* CSS2 properties" (emphasis
added), this should include the value "auto" in addition to avoid, left, right,
and inherit cited in the Description.  

See <URL:http://www.oakparkfoundation.org/grant_log.html>, which has a long
table after a short introduction.  The table begins printing on a new page
despite the use of 
  table { page-break-inside:  auto;
	  page-break-before: avoid }

After printing the first two paragraphs plus four lines, there is a page break
before printing the start of the table.  The start of the table should print on
the first page with the first two paragraphs plus four lines.  

CSS 2.1 replaced CSS 2.  I updated the Summary accordingly.  
Comment 42 Alastair Campbell 2005-11-24 04:10:44 PST
Since the advent of the S5 presentations (http://meyerweb.com/eric/tools/s5/) it would be very useful to have use of page-break-inside.

Adding this to the print style sheet:
.slide {page-break-inside: avoid;}

Would make it that much better in Mozilla/FF, I currently use Opera to print out the presentations I make.
Comment 43 Alex 2005-11-27 13:06:02 PST
When reading the CSS/2.1 specification, I found this:

I think that the "best" page breaks was taken too seriously.  The "best" page breaks (quoting CSS/2.1 Specification):

- Break as few times as possible.
- Make all pages that don’t end with a forced break appear to have about the
same height.
- Avoid breaking inside a block that has a border.
- Avoid breaking inside a table.
- Avoid breaking inside a floated element

However, the specification states this before (quoting again):

CSS2 does not define which of a set of allowed page breaks must be used; CSS2
does not forbid a user agent from breaking at every possible break point, or not to
break at all. But CSS2 does recommend that user agents observe the following
heuristics (while recognizing that they are sometimes contradictory):

(end quote)

It is more important to have the content fit within the margins of the page than to worry about breaking in the middle of tables and the like.  In "Allowed Page Breaks", however it is stated that any declaration of page-break-inside (set by default) can be dropped if the element will not fit on one page.

To end my essay, I propose these changes:

1. To set priorities to "best" page breaks; "Break as few times as possible" should be set before the times when breaking should be avoided (in the middle of tables, etc).  Otherwise, a table smaller than a page but too large to fit on the same page as content before it will be forced onto a new page even though it would be better to split the table (with the exception of CSS page-break-inside set to avoid).
2. The margins of the page are of first priority.  If it is impossible to break in compliance with the CSS, the declarations of the CSS must be dropped.  However, an element should be broken only if the element itself takes up more than one page; otherwise, it should be broken before.

Personally, I think the specifications are vague and in need of rewriting.  It seems they are aware of this ("while recognizing that they are sometimes contradictory"), but it is making it hard of web developers like myself.  It is annoying to have a div or a table split (no, I do not use tables for layout).
Comment 44 Gérard Talbot 2006-01-04 14:14:03 PST
*** Bug 322393 has been marked as a duplicate of this bug. ***
Comment 45 Dave Yost 2006-01-05 18:29:52 PST
Regarding the discussion of "best" page breaks.  For this bug, that is a distraction.  This bug is primarily about one thing:
  page-break-inside: avoid

Someone can open another bug to argue till the end of time about how to interpret "best" page breaks.  In the meantime, about a 42,000 of us out here have been waiting years with bated breath for this fix, which would seem to be trivial, considering that "page-break-before: avoid" works.
Comment 46 David E. Ross 2006-01-08 13:27:17 PST
This bug report is NOT only about "page-break-inside: avoid".  It's about all CSS 2.1 page-break properties.  To fix a single property in the area of page breaks for a single value is unacceptable when you consider the final, official CSS 2.1 recommendation (the closest W3C gets to issuing a standard) is expected this year.  
Comment 47 Dave Yost 2006-01-08 15:13:38 PST
The best is sometimes the enemy of the good.  Full compliance with 2.1 doesn't have to come all at once.  Some parts of it already work. The next step could be to make another part of it work. Say, for example, "page-break-inside: avoid".
Comment 48 Gérard Talbot 2006-01-10 00:28:33 PST
I want the many voters in this bug to know that&#13;&#10;&#13;&#10;1- now would be a good time to create useful, relevant testcases on CSS2.1 page-break-* properties. Why? &#13;&#10;   a) Mozilla Cairo Update - Printing, posted January 2006&#13;&#10;   http://www.pavlov.net/blog/archives/2006/01/mozilla_cairo_u.html&#13;&#10;&#13;&#10;   and more importantly:&#13;&#10;&#13;&#10;   b) Printing Bugs in Firefox, posted on December 19th 2005&#13;&#10;   http://weblogs.mozillazine.org/qa/archives/2005/12/#a009469&#13;&#10;which is a call for help/support: "Narrow down the cause of the problem the best you can so that the developer has a better chance at debugging it. Basically, find testcases in the bugs or develop your own simplified testcase that can be easily reproduced."&#13;&#10;&#13;&#10;2- page-break-* properties apply only to block-level elements in the normal flow of the root element according to CSS 2.1 (see section 13.3.1). So, applying page-break-* to, say, an abs. pos. element or a position:fixed element or to a table row (<tr>) or table-cell (<td>) is NOT covered by known spec, therefore should result in an undefined behavior.&#13;&#10;&#13;&#10;
Comment 49 Gérard Talbot 2006-01-10 00:38:22 PST
Created attachment 208068 [details]
Screenshot of print preview showing a page-break-inside: avoid failure

Steps to reproduce:

- load the page http://www.gtalbot.org/BugzillaSection/Bug132035_Page_Break_Inside_Avoid.html

- File/Print Preview (or even Print the 2 pages)
- Scroll between 1st and 2nd page

The dashed-bordered blocks (identifying <div>s with page-break-inside: avoid) should be completely on an unique page, not broken between 2 pages as seen on the screenshot.
Comment 50 David E. Ross 2006-01-15 12:06:58 PST
My test case (cited in comment #41) uses page-break-* on table elements, not table-row.  This is not a hypothetical case.  This is a real case, part of the Web site that I maintain for a charity.  

If only part of page-break-* can be fixed, I would prefer that page-break-before and page-break-after be completed for ALL values before starting to fix page-break-inside for any values.  After that, page-break-inside should be fixed for all values.  

Implementing a style-sheet property for only some values and then going off to implement a related property for only one value (e.g., {page-break-inside: avoid}) is not a valid development plan.  

In any case, I need {page-break-inside: allow} and {page-break-before: avoid} implemented.  (I would temporarily forgo the former if I could get the latter.)  At the present, I don't need {page-break-inside: avoid}.  
Comment 51 osakawebbie 2006-05-11 05:47:48 PDT
Created attachment 221697 [details]
Testcase #1, <p>'s with page-break-before:avoid

This is similar to real work I am doing.  Each section should be kept together, not split across pages.  This is the first of two methods I tried, both of which should work, if I understand the CSS2 spec correctly.
Comment 52 osakawebbie 2006-05-11 05:54:24 PDT
Created attachment 221699 [details]
Testcase #2, <div> with page-break-inside: avoid

The second of my two methods attempting to keep small sections of text together.  This method works in Opera.  These testcases are very simple, but I hope they will be helpful to developers.
Comment 53 mikhail 2007-03-16 06:17:06 PDT
Created attachment 258773 [details]
Page-break-after:avoid testcase

The idea is as follows:

If there is a huge object with a heading, there should be no pagebreak between the heading and the object.
Comment 54 Eli Friedman 2007-03-28 22:35:54 PDT
Okay, I've been thinking about the implementation of this a bit; I think I'd like some feedback on my thoughts before I dive into implementing this:

According to CSS2.1, certain page breaks are better than others (the exact suggested heuristics have been up in the air a bit, but it shouldn't matter too much for the implementation).  I'm planning on using a simple break ranking system to deal with this.

For a block with inline lines:
Tell the parent the highest rank of break possible within the block (2 if a break without ignoring page-break-inside, widows, or orphans is possible, 1 if a break without ignoring widows or orphans is possible, or 0 if no break is possible).

(My first patch probably won't include widows/orphans support to keep things simple.)

For a block with block lines:
while (moreLines) {
Reflow the next child line.
If the rank of the returned break within the line is greater than or equal to the rank of the best previously found break, record the rank and current line.
If the line didn't fit completely, stop reflowing lines.
Find the rank of the break opportunity after the block (3 if 'page-break-after' or 'page-break-before' associated with the break are 'always', 'left', or 'right', 2 if the 'page-break-before', 'page-break-after', and 'page-break-inside' properties are all auto, or 1 otherwise.  If the rank is greater than or equal to the rank of the best previously found break, record the rank and current line.  If the rank is 3, stop reflowing lines.
}
If the saved break is not after the last line reflowed, push all lines after the saved break onto the next page. Also, if the saved break is within a child line, reflow it again with a flag forcing it to break within itself.


The code needed to make this work is 
1. The code the calculate and pass around the ranks.  I'm thinking I'll put a variable onto nsHTMLReflowMetrics to allow passing the rank of the best break in a block back to its parent.
2. The code to push around lines once the break is calculated.

This approach is pretty straightforward, and shouldn't require major changes to the way we do block reflow.  (Not to say that it'll be easy; the block reflow code is a maze.)

I haven't really thought about how this interacts with columns. Column frames probably need to be propagate the break ranks up through reflow to work correctly.

I'm not sure how this might interact with incremental reflow; if I'm lucky, it will just work, but I somehow doubt that will happen.

This proposal address tables; they will require some more work (table frames, rowgroups, rows, and cells also need to propagate the break ranks to work properly; it shouldn't be too hard, but there are a few tricky bits, like rowspans, theads, and tfoots.)
Comment 55 Eli Friedman 2007-03-29 14:31:04 PDT
(Adding CCs for possible comments re: comment 54.)
Comment 56 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-29 17:30:59 PDT
That sounds good to me. Really good, in fact.

It will interact all right with incremental reflow if you cache the "best break rank" values in the right places (probably the nsLineBoxes for block children).

I think this should interact OK with columns. They can pass up their best break rank in a similar way as if they were blocks. Ditto tables.
Comment 57 Daniel.S 2008-09-20 14:55:13 PDT
*** Bug 403836 has been marked as a duplicate of this bug. ***
Comment 58 austin 2008-12-18 05:33:08 PST
i have been waiting patently for a long time for support of "page-break-inside:avoid". Please please can we have this some time soon
Comment 59 austin 2008-12-18 05:35:11 PST
i have been waiting patently for a long time for support of "page-break-inside:avoid". Please please can we have this some time soon.
Just to confirm i am using firefox 3.0.5 and page-break-inside:avoid does not work, either its a bug or its not yet supported.
Comment 60 Javier Serrano Polo 2008-12-21 00:56:40 PST
While waiting for the final implementation, you might be interested in this:
http://bugs.debian.org/509319
Comment 61 Artem Skoretskiy 2008-12-22 10:23:39 PST
Guys, please implement page-break-inside:void ! This bug is opened for 6 years already..
Comment 62 Garth Wallace 2008-12-22 11:36:22 PST
I assume you mean "avoid", because "void" is not a valid value for the page-break properties.
Comment 63 Artem Skoretskiy 2008-12-22 11:39:11 PST
(In reply to comment #62)
> I assume you mean "avoid", because "void" is not a valid value for the
> page-break properties.

Yes, I meant "avoid".
Comment 64 Charles Harrison 2008-12-22 16:15:27 PST
Yes, that's right!  6 years!  Why does nobody want to fix this?

There is no real workaround for this which doesn't potentially harm the environment by wasting paper.

For example, I have composed a page ...
	http://www.macfh.co.uk/Test/SatelliteGeneral.html
... which has a number of 'inserts' which the user can show or hide by clicking green 'toggles'.  The page will print including whatever the user has chosen to show, and therefore pagination is unpredictable.  However the final part, being a list of things required, needs to print on one page regardless of what happened higher up.  If you examine the code and scroll down to the comment I've inserted, you will see that I've tried to arrange this by enclosing the section in a div using ...
	style="page-break-inside:avoid!important;"
... but whether I include it as here or create a class and include it in the @media print {} section of the site stylesheet, it just doesn't work.

So on the live page ...
	http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteGeneral.html
... I've had to put a page break before the section.  However, if you play around with the toggles, and examine the resulting print previews, you will realise that some combinations waste paper by forcing a page break even though the section to be unbroken would have fitted on the current page.

Hardly ideal in the modern environmentally aware world where we are supposed to be everything to avoid the CO2 production involved in waste.
Comment 65 Daniel.S 2008-12-23 00:30:17 PST
@Artyom and Charles: Please don't repeat facts that are already known and written in this report.

This bug/request is already in the triage queue. It's good that you show interest. However, unnecessary comments are spam to the bug and make it less likely to be fixed.

FYI, here's a developers point of view to long-standing bugs: http://dbaron.org/log/20080515-age-of-bugs
Comment 66 Charles Harrison 2008-12-23 08:07:51 PST
I'd lie doggo if I were you.  Where it's taken 6 yrs to get CSS2 to triage, you're hardly in any position to complain!
Comment 67 osakawebbie 2008-12-23 16:11:25 PST
Please, people, let's not use this comment section to flame people.  Eli wants to try to fix this (see Comment #54), so let's either help him or stay out of the way.  It is a complex thing to code, so it may take some time to do it right.  If I had the time, I'd love to help with the code, but I don't, so I can only provide testcases (which I did) and cheer Eli on! :-)
Comment 68 Javier Serrano Polo 2008-12-24 00:25:09 PST
Just to make sure, comment #60 wasn't a reproach. It simply states that a foreign developer took the time to do it right. It looks like this statement isn't useful anyway.

This bug will be fixed only if a developer wants to. Cheering won't help. Whining won't help. Even your test cases won't help, because when it is done you'll need more complex cases (setting all breaks to avoid, mix with tables). The layout is in the core and core changes mean new ways to crash the application.

So, my humble advice, let this bug be totally quiet.
Comment 69 Srirama Shastri 2009-02-18 10:33:01 PST
I persuaded my client to switch to Firefox for of XYZ reasons and now I am stuck with the page-break-inside:avoid. Now I need to ask him to switch to opera or do some hack in the page (calculating page length using number of lines) and fix this issue. 

I feel this one of the important feature used in any decent intranet/internet web-application. Some one or other wants to print a report and we are stuck with the loose line on top of some page. Certainly client will ask can't we fix it. Either we need to fix it using Size of the page x number of lines or generate a PDF file. 

I hope mozilla-developers will realize it is an important feature and not something stupid feature request and put some development effort on it. BTW I am ready to help on this. I know Java, Javascript and work on LAMP.
Comment 70 David E. Ross 2009-02-21 10:32:19 PST
Before significant resources are expended to implement CSS3 capabilities (e.g., bug 70132), please complete the implementation of CSS2.1 capabilities (including this bug).
Comment 71 Daniel.S 2009-04-03 09:10:00 PDT
Safari doesn't know page-break-inside: avoid; but is fine otherwise. Adding parity.
Comment 72 Andrew Hagen 2009-05-20 07:20:22 PDT
*** Bug 198513 has been marked as a duplicate of this bug. ***
Comment 73 Andrew Hagen 2009-05-20 07:23:00 PDT
*** Bug 346918 has been marked as a duplicate of this bug. ***
Comment 74 Andrew Hagen 2009-05-20 07:24:30 PDT
*** Bug 330132 has been marked as a duplicate of this bug. ***
Comment 75 Andrew Hagen 2009-05-20 07:37:34 PDT
*** Bug 445212 has been marked as a duplicate of this bug. ***
Comment 76 Andrew Hagen 2009-05-20 07:41:18 PDT
*** Bug 332531 has been marked as a duplicate of this bug. ***
Comment 77 Andrew Hagen 2009-05-20 07:53:33 PDT
We have various problems that affect the CSS properties page-break-*. In case they turn out to be related, here is a list. 

Bugs that report crashes, assertions, memory leaks, or hangs that seem to be associated with page-break-*: bug 334491, bug 470851, bug 407085, bug 470974, and bug 399994. 

There are various reports of regressions that affect page-break-*, such as bug 445212 -- reporting a regression between Firefox 2.0.0.14 and 2.0.0.15.
Comment 78 Andrew Hagen 2009-05-20 08:39:05 PDT
*** Bug 278251 has been marked as a duplicate of this bug. ***
Comment 79 Andrew Hagen 2009-05-20 09:06:49 PDT
*** Bug 429476 has been marked as a duplicate of this bug. ***
Comment 80 fantasai 2009-05-20 09:38:36 PDT
Andrew, I appreciate that you're trying to bring together related bug reports, but most of these do not seem to be duplicates of this bug, they are merely related. Can you please unduplicate them?
Comment 81 Andrew Hagen 2009-05-20 12:13:52 PDT
This bug matches those bugs. I don't see how they can be broken into different bugs.
Comment 82 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2009-05-20 12:52:56 PDT
If you're marking a bug duplicate, you're saying that you're confident that a fix for this bug would also fix that bug (without anybody having to look at the details of that bug).  If that's not the case, you should mark a dependency rather than a duplicate.
Comment 83 fantasai 2009-05-20 15:12:29 PDT
Rewording the summary so it's more clear. "Support all page-break-* CSS2.1 properties" is really general, so I think Andrew thought bugs in our existing page-break-* support should be duped here. As evident from the description, that's not really what this bug's about, it's about adding the missing features.
Comment 84 Dave Yost 2009-07-10 09:52:32 PDT
Yes, yes, yes! Make this block a release!
Comment 85 valerasv 2009-07-24 04:51:06 PDT
Please add support for "page-break-inside: avoid".
Comment 86 Tony Birnseth 2009-08-23 21:15:33 PDT
Thought this was to be released in 3.5!
I've been waiting over a year and a half having to keep my customers on 2.15 instead of 3.x.  Without the change for 'page-break-after:always;', I can't support FF 3.x for my application.  This is crippling!

The other issue preventing migration to 3.x is the non-modal nature of the window.print implementation (been waiting the same amount of time and was also supposed to be released in 3.5).  This one two has me crippled.  I either have to tell clients to stick with 2.x or use (dreaded) IE.

Trying to be patient since I fully realize this a voluntary work.  But a year and a half is a long time!
Comment 87 Steffen Wilberg 2009-10-08 05:59:57 PDT
(In reply to comment #86)
> I've been waiting over a year and a half having to keep my customers on 2.15
> instead of 3.x.
Firefox 2 is unsupported since December 2008 and has known security vulnerabilites.

> Without the change for 'page-break-after:always;', I can't
> support FF 3.x for my application.
Are you still referring to bug 445212?
page-break-after: always works just fine with block-level elements like <p>, <div> or <img>, see the first testcase in this bug (attachment 119787 [details]).
Comment 88 Francesco Gigli 2009-10-08 06:29:17 PDT
For me is "page-break-inside: avoid" that is not working.

Should i provide an example html testcase?
Comment 89 Steffen Wilberg 2009-10-08 06:52:19 PDT
No(In reply to comment #88)
> For me is "page-break-inside: avoid" that is not working.
> Should i provide an example html testcase?
No, that's covered by attachment 221699 [details].
Comment 90 Alain-Christian 2009-10-14 18:19:09 PDT
I've found that "overflow:hidden;" can cause problems and stop pages from breaking. This can be fixed with "overflow:visible;" when media types are specified.
Comment 91 austin 2009-10-25 02:34:52 PDT
The feature "page-break-inside: avoid" has been required for many years, and no developer would appear interested in developing it. 
Firefox 3.5 does support 'page-break-after:always;' at least.
If this feature is important then maybe consider using Chrome, the new version is also a very good browser.
Comment 92 Alain-Christian 2009-10-25 13:33:10 PDT
Switching browsers, instead of fixing the problems with this one which a significant number of people use, eh? That's a very intelligent and thought out idea! Why, after switching to Chrome I should probably detect which of my visitors aren't using it and pop up a message telling them to switch, right? Perhaps even place an image at the base of all my pages telling my visitors that the page is optimized for Chrome? I should probably also prevent non Chrome visitors from even getting past the homepage, right?

Why don't more people do that? You, Mr. Austin, are a GENIUS!
Comment 93 d 2009-10-25 13:53:26 PDT
He/You have a point though. Mozilla really needs to fix these last CSS2(.1) parts that are left, which isn't much. When the IE team has managed to do it, sure you can ;)
Comment 94 Blu3 2009-10-25 16:28:43 PDT
i don't want to sound as trite as this comes off, but seriously - if a vendor (mozilla) can't or won't fix problems after several -years-, why should you or anyone get upset if someone recommends switching to a different browser?

that's the #1 reason why a new software package takes off and gains a huge amount of traction - the old software maker has become a stick in the mud.  it's the natural cycle of how software grows and dies and there's nothing wrong with it.

people, myself included, don't have the time to make this happen ourselves, or some people lack the skill.  but we don't bill ourselves as mozilla developers.

a lot of people have been asking for these to be facilitated for years. this bug is 7½ years old.  it's unreasonable to expect people to wait for a third of their life for web pages to print out reasonably.

i've been a loyal FF user for a long time.  but these days i'll submit patches to other browsers that actually make progress.  even IE is improving far more significantly than FF and that's the lowest of lows for my opinion of browsers.

i'd love to see mozilla turn things around rather than being crass and snarky with people who use, or used to use mozilla software.  instead, devs (and users) are curiously rude to people who ask for fixes like it might somehow make the problem code more acceptable.
Comment 95 d 2009-10-25 16:39:04 PDT
There seems to be a connection between high marketshare and slow development, look at the history of Internet Explorer and Firefox. Let's hope that Firefox sobers up and starts getting support at the rate it used to do.

Look at Webkit, they've suggested at least five amazing things the past two years, and implemented lots of stuff. You are having to even implement finished standards.

Still, kudos (or whatever you say) to Mozilla for having such a "bug-free" implementation of what is actually supported. Almost everything is supported to it's fullest.
Comment 96 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-10-25 18:00:26 PDT
Within the last 18 months we have implemented many new CSS-related features, including CSS gradients, CSS 2D transformations, CSS transitions, CSS3 background-size, CSS3 border-image, CSS3 box-shadow, CSS3 text-shadow, CSS3 border-radius, CSS3 multiple backgrounds, SVG animation of CSS properties, SVG 'clip-path', 'mask', 'filter', 'image-rendering' and 'pointer-events' CSS properties working on non-SVG content, and CSS @font-face font loading. We have also fixed many major bugs in areas such as :before and :after handling and anonymous table box construction. We have made many performance improvements. (And there is a ton of non-CSS stuff happening too, of course.) Is that what you call slow development?
Comment 97 Joshua Cranmer [:jcranmer] 2009-10-25 18:06:47 PDT
Out of curiosity, what ever came of Eli's attempt?
Comment 98 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-10-25 18:16:51 PDT
Eli moved on before he did any work on it.

By the way, advocacy comments like comments #91 - #96 are inappropriate and not helpful to getting this bug fixed. I apologize for yielding to the temptation. We know this bug needs to be fixed, and it's simply a matter of development priorities now. General advocacy comments are pointless since almost every bug attracts them; every bug is *some* user's top priority.
Comment 99 d 2009-10-25 18:29:40 PDT
Not at all. When I looked at my post again, I felt that it expressed things in a way that I didn't mean.

I am also well aware of the CSS implementations you mentioned, but somehow Webkit has managed to implement the same things, and several other new CSS technologies.

I am sorry, and after all I know that Gecko is a really good engine, with (correct) support for very much. After all, that is one of the major reasons I use Firefox.

But I'd like to add that I am not alone to have this view on the current situation, see http://idreamincode.co.uk/browsers/saying-goodbye-to-firefox for example. While I can not point out exactly why, there is something that makes people feel this way.

I think that the fact that you've been the leader in implementing new things in many areas of web development has lead to a problem, now when people no longer can compare only Internet Explorer and Firefox when recommending a browser, after seeing Webkit support many things better than Gecko.

Webkit CSS transitions are coming, and that is great, and while we'd love to see more of those, can't you take a month or two to finish off CSS2 support so that you can focus all the time on CSS3 later on?

Here's a great page to track progress on:

http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Cascading_Style_Sheets%29

As you can see, there isn't much left, and that green color which Internet Explorer has on CSS 2.1 makes it look like you have less support for CSS in general. It would be nice to have a change in that.

Finally, to conclude, as I have said earlier, I am aware that when Gecko gets support for something new, you tend to do it very well.

I put together a test (it is a bit messy) which proves that:

http://www.zirro.se/code/ph0/newtest.html

Webkit actually does worst in that, because they usually rush their support a bit, which means that bugs and lack of support of certain values might come as a consequence.

I'm sorry for calling it slow development, which might actually be something good as things gets done properly. Just fix these 5+ year old bugs ;)
Comment 100 Blu3 2009-10-25 18:40:59 PDT
robert, CSS3 is to be loved.  i certainly won't dissuade such opinion. 
transforms, transitions, shadows etc are all neat and new for moz developers.
but there are a lot of web developers and users that want basic things. 
advocacy comments re. #91-96 show because this bug has languished for seven
years and has a lot of people watching it.  as the years go by, it's more and
more likely that frustration will bubble up like this.  i don't think general
advocacy is pointless because it is a meter of what the rest of us outside the
developer circle are interested in.  things like page-* are particularly
applicable for more professional or corporate designs.
Comment 101 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-10-25 19:30:35 PDT
(In reply to comment #99)
> somehow Webkit has managed to implement the same things

Webkit doesn't implement 'clip-path', 'mask', 'filter', and 'image-rendering' for non-SVG content. And for many of the things they do implement, their implementation is not as good, as you note.

> But I'd like to add that I am not alone to have this view on the current
> situation, see http://idreamincode.co.uk/browsers/saying-goodbye-to-firefox
> for example. 

Whatever that post means, it was written in March 2008, before all of the things I mentioned were done.
Comment 102 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-10-25 19:47:08 PDT
Anyway, regardless of which engine is better, one thing I can say for sure is that we got a lot more CSS-related work done over the last 18 months than at any other time in Mozilla's history, so perceptions that we're "slowing down" are simply wrong.

And that is all irrelevant to this bug, unless your goal is to anger and frustrate Mozilla developers who are already working hard.
Comment 103 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2009-10-25 20:05:14 PDT
(In reply to comment #99)
> Webkit CSS transitions are coming, and that is great, and while we'd love to
> see more of those, can't you take a month or two to finish off CSS2 support so
> that you can focus all the time on CSS3 later on?

I agree that page-break-* are important.  But I don't think that has anything to do with what version of CSS they're in, and I don't think the version of CSS they're in is a helpful argument, for reasons similar to the ones I described in http://dbaron.org/log/20080515-age-of-bugs  (On the other hand, which other browsers implement them is relevant, since it affects whether our implementation of them would be useful to authors immediately.  And how useful the features are to authors and users is, of course, also relevant.)
Comment 104 Alain-Christian 2009-10-25 21:38:47 PDT
I'm not sure what an advocacy comment is but my response to Mr. Austin (#92) was an effort to show him how silly his suggestion was. The poor guy is stuck in the 90's, I'm afraid.

Anyhoo, if I knew a thing or two about a thing or two you can bet I'd be working on a fix/patch. I've done so for other products. The first comment I posted (#90) was to help and give clues to anyone that might be working on this at the moment. This bug is also the reason the joined Mozilla in the first place, heh. I hope I haven't opened a can of worms.


BTW, Mozilla is not a single entity.

People volunteer to fix bugs. So if no one volunteered to fix this, it's going to linger. In a way, you can't really blame anybody. The best you can do is hope more people like me sign-up and vote for this bug to get fixed.

It doesn't irk me that CSS3 stuff seems to be at a higher priority than CSS2 stuff. Perhaps it's just easier to implement and code for than what's left to implement in CSS2. I mean, volunteers are going to pick the low hanging fruit, it's inevitable.
Comment 105 Alain-Christian 2009-10-25 21:40:14 PDT
Oh God, I used 90's instead of 90s. My apologies for making such a ghastly grammar mistake.
Comment 106 fantasai 2009-10-25 23:48:35 PDT
Hilarious. I think I'll give you all a status update on this, since it's been on my radar (and in several of my contracts) for years now. Basically every time I've sat down and looked at this bug, I've been sidetracked by wanting to refactor something first. That seems a lot less necessary now. A lot of work has gone into Gecko's layout engine at the architectural level over the past release cycle (on the current trunk), and in particular a number of improvements that would make implementing this feature easier and cleaner. These include things like cleaning up float continuations (bug 492627), and double-linking the frame list (bug 512336 and related nsFrameList fixes). There's 2 bits of remaining work that I consider prerequisite:

1. The current page-break implementation for forced breaks needs to be ripped out and replaced. It's just a really poor fit for our architecture, and interferes with a lot of code that isn't expecting some of the stupid things it does.

2. The terminology for page breaks, line breaks, and clearance (from floats) is really mixed up in the layout code, and before attempting to add another layer of logic to nsBlockFrame that talks about "breaks", I think it would be good to do some superficial cleanup of the interfaces and comments involved.
Comment 107 austin 2009-10-26 14:08:44 PDT
WOW, what have i done. I agree with Fantasai this is hilarious mainly that Alain-Christian should take my comment so personally and then feel the need to attack me and my suggestions. Very very rude.

Just to be clear, i think FF is great, I did not knock it or say Chrome is better or even compare them.  I use FF every day for general browsing, however i/we have to use Chrome when accessing one intranet because of this missing css and printing without it is unsuitable. In doing so i have found it ALSO to be a good browser.

Alain i suggest that if you are a professional person your future posts will be constructive to the issue, however i doubt it.

Fanasai your post gives me hope, good luck.
Comment 108 Alain-Christian 2009-10-26 15:01:11 PDT
LOL @ Austin speaking out of both sides of his mouth. "Do as I say, not as I do!" Hahaha!

Dearest Pot,
The way you presented your suggestion the first time hearkened back to the days when authors checked for user agents instead of user agent FEATURES. Your clarification makes a lot more sense and I get your meaning now. I'd passive-aggressively suggest you double-check your posts before submitting them but I won't since this is coming from the guy that only spotted a grammar gaffe AFTER he submitted a post of his own.

For the record I wasn't attacking you personally, I was attacking the antiquated idea of targeting user agents. Frankly, I'd do it again! It's up to all self-respecting authors to stamp out that kind of thinking like it was Polio!

Your Friend,
-Kettle
Comment 109 Jeff Walden [:Waldo] (remove +bmo to email) 2009-10-26 16:52:57 PDT
Regardless how justified or unjustified comment 108 may have been, the name-calling in it is out of order, particularly in the context of a comment which entirely lacks any information useful in fixing this bug.  I believe it constitutes personal abuse:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Unless you are providing information directly useful in fixing a bug, please refrain from commenting, and in all cases refrain from gratuitous name-calling.
Comment 110 David E. Ross 2009-10-28 13:40:57 PDT
In which Gecko version has this been fixed?
Comment 111 d 2009-10-28 13:47:16 PDT
It hasn't been fixed, unfortunately . If it was, we wouldn't be having a discussion here now.
Comment 112 David E. Ross 2009-10-28 15:47:21 PDT
Oops!  I posted comment #110 in the wrong bug report.
Comment 113 Sebastian Zartner 2010-01-07 07:45:38 PST
I think, this is a feature, many people are missing (already 141 votes for that!). Why are the page-break-* features still not implemented? In general FF should finally implement all CSS 2.1 features. It's out for many years now and CSS 3 is already knocking on the door.

PS: Alain-Christian should be banned for his comments against austin!
Comment 114 David E. Ross 2010-03-24 18:18:12 PDT
The chart at <https://developer.mozilla.org/En/Mozilla_CSS_support_chart> indicates (1) that ALL of CSS 2.1 is implemented and (2) that page-break-* are CSS 3 features.  However, the page-break properties are specified in Section 13.3 of the current (8 Sep 09) "W3C Candidate Recommendation" for CSS 2.1.  

This is not the only case I have discovered where the "Mozilla CSS support chart" improperly attributed a CSS 2.1 feature to CSS 3, thereby making the false assertion that all of CSS 2.1 is implemented.  Another case is the @page feature cited in bug #115199.
Comment 115 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-03-24 18:43:23 PDT
(In reply to comment #114)
> The chart at <https://developer.mozilla.org/En/Mozilla_CSS_support_chart>
> indicates (1) that ALL of CSS 2.1 is implemented and (2) that page-break-* are
> CSS 3 features.  However, the page-break properties are specified in Section
> 13.3 of the current (8 Sep 09) "W3C Candidate Recommendation" for CSS 2.1.  
> 
> This is not the only case I have discovered where the "Mozilla CSS support
> chart" improperly attributed a CSS 2.1 feature to CSS 3, thereby making the
> false assertion that all of CSS 2.1 is implemented.  Another case is the @page
> feature cited in bug #115199.

The specification links in that chart generally point to the newest specification, not the oldest.  I find that somewhat confusing too, but, then again, I didn't write it.  If you want to fix it, you're welcome to, as it's a wiki; I don't have the time to fix it right now.

However, complaints about that chart don't belong in this bug.
Comment 116 Boris Zbarsky [:bz] (still a bit busy) 2010-07-20 11:34:38 PDT
*** Bug 580312 has been marked as a duplicate of this bug. ***
Comment 117 Daniel Schatzle 2010-09-03 13:08:51 PDT
(In reply to comment #90)
> I've found that "overflow:hidden;" can cause problems and stop pages from
> breaking. This can be fixed with "overflow:visible;" when media types are
> specified.

Wanted to second the problems with overflow.  Just ran into this same issue.  Print preview displayed the first page of content and the rest was lost in space.  Changing to overflow:visible fixed it right up.
Comment 118 Ken Haase 2010-09-20 09:07:15 PDT
I'm glad I missed the flamefest, but it's disappointing that these CSS2.1 features aren't yet implemented.  I'd always thought of Firefox as being at the vanguard of standards compatibility and am adjusting that impression.  Are they implemented in FF4?  

On top of not being implemented, it looks like the 'avoid' values aren't even represented in the DOM CSS, which is especially annoying if one is rolling ones own page-based functionality.
Comment 119 Ryan VanderMeulen [:RyanVM] 2010-09-20 10:22:47 PDT
If this bug were implemented for Firefox 4, it would be marked RESOLVED FIXED. As it is, this bug has never even had a patch posted to it, so no, it is not implemented in any way in the Mozilla source code.
Comment 120 David E. Ross 2010-12-26 13:43:17 PST
Re:  coment #41

Someone else is now the Web master for the Community Foundation for Oak Park. 
Contrary to the best practices for foundations, the Web site no longer contains
a list of grants issued.  I retrieved the Web page cited in comment #41 from my archives and set it up as <http://rossde.com/test/large_tables.html> for use as a possible test case.
Comment 121 u335068 2011-02-27 12:45:32 PST
Will these unimplemented CSS 2.1 properties ever get attention? Still not working as of Firefox 4.0 beta 11.

Browsers supporting this property: Opera 11, Internet Explorer 8 (!)

Other browsers not yet supporting this: Safari 5 (Win), Chrome 9 (Win)
Comment 122 fantasai 2011-02-28 12:31:46 PST
Pester me about it sometime in late June or July. :) But not in the bug report.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Comment 123 Thomas Ahlblom 2011-05-08 18:55:12 PDT
*** Bug 655634 has been marked as a duplicate of this bug. ***
Comment 124 David E. Ross 2011-05-25 12:07:34 PDT
The CSS2.1 specification is scheduled to reach its final "Recommendation" state next month (which begins next week).  page-break is a capability contained in that specification.  

Raising the Importance from Normal to Major.
Comment 125 NeMewSys 2011-05-25 15:54:06 PDT
PLEASE!! Include page-break-inside:avoid on that spec. Please....
Comment 126 David E. Ross 2011-06-08 10:52:53 PDT
Today, CSS 2.1 reached "Recommendation" status.  See <http://www.w3.org/2011/05/css-pr>.  The lack of page-break* capabilities as defined in CSS 2.1 now represents a "major loss of function" without any work-around.  That is the definition of Severity = Major.
Comment 127 NeMewSys 2011-06-08 11:15:26 PDT
(In reply to comment #126)
> Today, CSS 2.1 reached "Recommendation" status.  See
> <http://www.w3.org/2011/05/css-pr>.  The lack of page-break* capabilities as
> defined in CSS 2.1 now represents a "major loss of function" without any
> work-around.  That is the definition of Severity = Major.

By other words: it sucks.
Comment 128 Mikko Rantalainen 2011-08-30 00:48:38 PDT
Before adding any new comments to this bug read the following comments:

Bug 132035 Comment 54
Bug 132035 Comment 56
Bug 132035 Comment 98
Bug 132035 Comment 103
Bug 132035 Comment 106
Comment 129 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-09-03 06:01:30 PDT
Actually fantasai is planning to work on this.
Comment 130 Scott Johnson (:jwir3) 2011-09-03 18:08:53 PDT
Ok, sorry. I'll relinquish the assignment then. It wasn't clear to me, since comment 106 was written almost 2 years ago. :)
Comment 131 Chris 2011-09-04 22:23:50 PDT
Created attachment 558222 [details] [diff] [review]
Can do divs, paragraphs, simple tables and columns (some part of table is still broken)

Quick fix hack that works surprisingly well for many cases. Tables are mostly not quite working except the most basic tables.
Comment 132 Chris 2011-09-04 22:32:40 PDT
Created attachment 558223 [details]
proposed testsuite (to be converted to reftests)

I created these files by using cairo's PDF output (in a custom XULRunner build). They serve to demonstrate the proof of concept. I am not sure how I can port it reliable to reftest.

Supposedly I will insert "hard" page-breaks on the reference page, but that will be very dependent on the page-size that reftest use. Also, column breaks are tricky. Any ideas?

(The table tests demonstrate the patch is not complete. They are included here as reference.)
Comment 133 fantasai 2011-09-05 00:43:55 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #129)
> Actually fantasai is planning to work on this.

Actually, Chris (kizzx2) and I will be working on this together, since he's already put together a patch for page-break-inside: avoid. :) So he'll write, I'll review, and we'll flag you for sr once it's all right. And then the other page-break stuff will be remaining. Which actually makes me think we should open up a separate bug for page-break-inside, since this seems to be more of a tracker for all page-break-* issues...
Comment 134 fantasai 2011-09-06 15:50:17 PDT
Filed bug 685012 for page-break-inside. I'll post review comments there.
Comment 135 Bernd 2011-09-06 22:58:21 PDT
re Attachment #558223 [details] from my experience with reftests I would replace long texts by divs with visible borders, otherwise you will end with non reproducible pixel errors on the edges of the letters.

see http://mxr.mozilla.org/mozilla-central/source/layout/reftests/pagination/ the table test cases for reference.
Comment 136 fantasai 2011-09-06 23:33:44 PDT
Comment on attachment 558222 [details] [diff] [review]
Can do divs, paragraphs, simple tables and columns (some part of table is still broken)

(See bug 685012 comment 3 for comments.)
Comment 137 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2011-09-07 08:29:55 PDT
(In reply to Bernd from comment #135)
> re Attachment #558223 [details] from my experience with reftests I would
> replace long texts by divs with visible borders, otherwise you will end with
> non reproducible pixel errors on the edges of the letters.

I think that's bad advice:  if the test cases should render identically, then use of text shouldn't be a problem.  In the past text has sometimes been a problem in testcases that aren't actually identical because there's a sub-pixel positioning difference (which shows up on only some platforms) or because there's a difference in what is being clipped (same), but it should not be a problem in general.  If it is we need to figure out why and fix it.
Comment 138 Richard A Milewski[:richard] 2011-09-20 22:06:51 PDT
Re comment 108:  Some of us out here who are web application authors are still checking user agents instead of user agent FEATURES because many of the "features" of the various user agents that are critical to smearing ink on paper with even a modicum of precision expose no interface to support such a check.   If I want to print a page, ostensibly a topic related to this bug, please explain to those of us who do not wish to remain "stuck in the 90's" how we test "modern" browsers for:

    * How close to the edge of the page a block with ZERO margin will print.
    * What the maximum printable width is on a standard sized sheet.
    * What the maximum printable height is on a standard sized sheet.
    * How much of a 10.5in block will appear on the SECOND 11in printed page.
    * Whether or not setting the "scale" in print setup actually affects scaling.
    * Where fixed positioning actually puts an element on the physical page. 
    * What the default x and y position shift is between screen and printed page.

Each "modern" browser seems to handle these issues differently, and in most cases the same browser handles these issues differently on different operating systems.

Could someone who truly understands what's going on please do a blog post somewhere that shows how to test for (and control) these issues.   Absent that, I believe we still need to sniff for user agents and special case the code accordingly.  Please, please, please prove me wrong.
Comment 139 Mardeg 2011-09-20 22:44:04 PDT
(In reply to Richard A Milewski[:richard] from comment #138)
>     * What the maximum printable height is on a standard sized sheet.
Which standard? A4 is the standard in my country.
>     * How much of a 10.5in block will appear on the SECOND 11in printed page.
Inches aren't how pages are measured here, yet I have en-US in my useragent string.
These comments (including mine) are against https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and further discussion should be done elsewhere.
Comment 140 Carlo Alberto Ferraris 2011-09-20 22:49:09 PDT
Just a quick note because I don't see the relevant tags in the bug description: both Opera 11 (previous versions as well) and IE 10 (the preview available in the W8 image) support page-break-* at least to some extent. I don't have Chrome so I can't test that.
Comment 141 Sebastian Zartner [:sebo] 2012-08-30 22:39:05 PDT
fantasai, you're the editor of the current WD[1] and the assignee of this bug, so I really wonder why Firefox is the last browser not having this feature implemented yet. It should have been playing a leading role here.

Is there any progress since comment 136?

Sebastian

[1] http://www.w3.org/TR/css3-break/
Comment 142 fantasai 2012-08-31 10:03:18 PDT
> Is there any progress since comment 136?

Yes, the task has been reassigned to mats, and I'll be guiding him inasmuch as I can. I'm unfortunately responsible for too many CSS specs these days to write code. :( See bug 775628 for tracking.
Comment 143 Boris Zbarsky [:bz] (still a bit busy) 2013-05-31 19:42:10 PDT
*** Bug 877383 has been marked as a duplicate of this bug. ***
Comment 144 Florian Bender 2014-02-01 12:31:54 PST
Adding some bugs in current implementation as "see also" though I'd rather add them as dependencies …
Comment 145 j.j. 2014-02-01 19:30:06 PST
> Adding some bugs in current implementation as "see also"

"See Also" usually refers to bugs in other projects.
Comment 146 Gordon P. Hemsley [:GPHemsley] 2014-02-02 07:57:47 PST
(In reply to j.j. (mostly inactive) from comment #145)
> > Adding some bugs in current implementation as "see also"
> 
> "See Also" usually refers to bugs in other projects.

That's not true. "See Also" can be used for BMO bugs that are related but not strictly within the blocker/dependency hierarchy.

(In reply to Florian Bender from comment #144)
> Adding some bugs in current implementation as "see also" though I'd rather
> add them as dependencies …

What was the reason that you didn't?
Comment 147 Florian Bender 2014-02-02 09:40:47 PST
(In reply to Gordon P. Hemsley [:GPHemsley] from comment #146)
> (In reply to Florian Bender from comment #144)
> > Adding some bugs in current implementation as "see also" though I'd rather
> > add them as dependencies …
> 
> What was the reason that you didn't?

This bug is about "implementing missing" features (though I did not check the dependant bugs if this is exclusively) and not about bugs in the current implementation per se. I still think however they are to be mentioned in this context, so I added them as "see also". If you feel this bug should cover them as dependancies, feel free to add them to the respective field – I think they should because they are essentially breaking 2.1-compliance and thus may count as "missing" features (even though this bug is not tracking compliance, initially).
Comment 148 j.j. 2014-02-02 13:10:41 PST
(In reply to Gordon P. Hemsley [:GPHemsley] from comment #146)
> (In reply to j.j. (mostly inactive) from comment #145)
> > "See Also" usually refers to bugs in other projects.
> 
> That's not true. "See Also" can be used for BMO bugs that are related but
> not strictly within the blocker/dependency hierarchy.

I said "usually", "can be used" might be true, but the definition is:

 "This allows you to refer to bugs in other installations. ... 
  You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the Depends on and Blocks fields."

I read "this installation" as "https://bugzilla.mozilla.org/"
and "other installations" e.g. as
"https://bugs.webkit.org/" or "https://issues.apache.org/bugzilla/" or "https://www.w3.org/Bugs/Public/".
IMHO it makes sense to use "See Also" for any other bug tracking system, e.g. "http://bugs.jquery.com/" or "http://code.google.com/p/chromium/issues/"
Comment 149 Gordon P. Hemsley [:GPHemsley] 2014-02-03 06:25:09 PST
(In reply to j.j. (mostly inactive) from comment #148)
> (In reply to Gordon P. Hemsley [:GPHemsley] from comment #146)
> > (In reply to j.j. (mostly inactive) from comment #145)
> > > "See Also" usually refers to bugs in other projects.
> > 
> > That's not true. "See Also" can be used for BMO bugs that are related but
> > not strictly within the blocker/dependency hierarchy.
> 
> I said "usually", "can be used" might be true, but the definition is:
> 
>  "This allows you to refer to bugs in other installations. ... 
>   You should normally use this field to refer to bugs in other
> installations. For bugs in this installation, it is better to use the
> Depends on and Blocks fields."

Fair enough. I didn't look at documentation for it.

The way I see it, though, "better" does not mean "required", and I think the fact that bugs in "this installation" are reduced to regular bug links ("bug XXXXXX") supports my interpretation of the "See Also" field being applicable to any bug in any installation that is not strictly a dependency or a blocker.

Either way, though, we've now taken this discussion way off topic.
Comment 150 matthew.d.sigley 2014-03-05 10:06:15 PST
Any progress being made here?

At this point this bug is 12 years old, and should really be put to rest. I have been waiting since 2008 for this to be resolved.

Also at this point, all other browsers, including Chrome and IE, have a very functional implementation of page-break-inside:avoid that works with images.
Comment 151 Gérard Talbot 2014-03-05 11:17:53 PST
(In reply to matthew.d.sigley from comment #150)

> at this point, all other browsers, including Chrome and IE, have a very
> functional implementation of page-break-inside:avoid that works with images.

Matthew,

please provide a *_valid and reduced testcase_* demonstrating what you are suggesting here and I will create a bug report accordingly. Please try to be constructive and relevant.

Right now, Firefox 19+ passes this test
http://www.gtalbot.org/BugzillaSection/Bug132035_Page_Break_Inside_Avoid.html
and passes this test
http://www.gtalbot.org/BugzillaSection/Bug685012-page-break-inside-avoid.html
and Firefox 19+ passes other page-break-inside: avoid tests (listed in CSS2.1 test suite) and both bug 685012 and bug 883676 have been resolved.

Gérard
Comment 152 Robert Utasi [:hunboy] 2014-03-05 18:36:11 PST Comment hidden (spam)
Comment 153 Sebastian Zartner [:sebo] 2014-10-30 05:48:28 PDT Comment hidden (obsolete)
Comment 154 :Gavin Sharp [email: gavin@gavinsharp.com] 2014-11-01 00:51:59 PDT Comment hidden (obsolete)
Comment 155 Sebastian Zartner [:sebo] 2014-11-01 01:14:00 PDT Comment hidden (obsolete)
Comment 156 Christopher Yeleighton 2014-11-08 09:52:28 PST Comment hidden (obsolete)
Comment 157 matthew.d.sigley 2016-02-17 10:55:23 PST Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.