Open Bug 136714 Opened 23 years ago Updated 2 years ago

Page-break-after:always doesn't cause page break inside tables

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: r-mcdonald, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(1 file)

testcase from comment 0
(deleted), text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002040813 If the page-break-after command appears *within a table cell*, it does not cause a page break. IE 5.5 *does* break a page in this case. It's not clear to me if this is an illegal use of page-breaking, but it's going to be a show-stopping compatability issue at my site. Reproducible: Always Steps to Reproduce: Load the html below and use print preview. Actual Results: Both lines print on the same page Expected Results: Both lines should (I think) print on different pages. They do in IE Here is code demonstrating this behavior <html><head> <style> PRE {page-break-after: always} </style> </head> <body> <table><TR><TD> <table> <TR><TD>Here is some text </TD></TR> </table> <pre></pre> <table> <TR><TD>Here is some text </TD></TR> </table> </TD></TR> </table> </body> </html>
->future p2
Assignee: rods → karnaze
Priority: -- → P2
Target Milestone: --- → Future
Robert, if you could put the page-break-after:always inside the row, I think that would work (unless possibly if it is the last row in the table).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You may be right but when I modify my example the only way I can get the page-break to work reliably is by putting the code between tables. Maybe it's a last row problem. I should also say that this isn't my code design. We have a reporting system which generates HTML that looks like what I posted. I'm just a user who was trying to figure why only Mozilla wasn't working.
Priority: P2 → --
Target Milestone: Future → ---
Priority: -- → P2
Target Milestone: --- → Future
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
Component: Printing → Layout: Tables
QA Contact: sujay → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
I tried to fix that by adding a page-break-after:always property to the row itself, but it happens that's worse : the page break does occur, but the part of the table after the row just doesn't print !
*** Bug 202927 has been marked as a duplicate of this bug. ***
Summary: Page-break-after:always doesn't cause page break → Page-break-after:always doesn't cause page break inside tables
Blocks: 234414
According to CSS 2.1, this bug is invalid. See http://www.w3.org/TR/2004/CR-CSS21-20040225/page.html#page-break-props , which says: These properties only apply to block level elements that are in the normal flow of the root element.
David Baron, Irregardless whether "technically" this is a bug against the specification or not, not supporting this capability gives Mozilla a huge weakness compared with IE in this area! I am giving a HUGE vote that this item be addressed ASAP. Please, the alternative for us is a redesign to support Mozilla with our application. The initial comment future P2 what does that indicate? Is there anyway this bug/enhancement can be targeted for the next release? Please. Thanks in advance for your consideration, Jim
I will (very reluctantly) second Jim Wilcox on this. To be blunt, our internal database application spits out some of the ugliest HTML, with page breaks within tables nested in tables, that I have ever seen. But, despite my discussions with the maintainers, it is what it is and it is likely to remain so. Therefore as a practical matter, it is impossible at our site to rely solely on Mozilla unless this issue is addressed. Please treat this comment as an FYI, not as a complaint; I am quite grateful to the Mozilla team for all their hard and excellent work.
Just to second some of the comments previously made - if we want to be able to get our users off of IE, we really need to address this issue (sooner = better). In our case, we have very large reports which are using a table, and some rows within that table act as "subtotal" rows - when people ask for page breaks after every subtotal line, its a difficult sell for us to explain that "well we can't really do that because CSS doesn't support that"...their response is to say that "well IE handles it just fine!" In our case, the only solution would be to completely restructure the reports so that every section is self-contained in its own table - but that doesn't fit our requirements in terms of look and feel for the user interface. All this to say, I really think this is a legitimate bug (in practical terms of user requirements, comparison with IE), even if CSS doesn't actually mandate it work this way (I don't think the CSS defn is actually prohibiting the requested behavior is it?)
If you want this implemented, the first step would be to define _how_ it should be implemented. Given two cells side by side, one which says page-break-before always, and the which says page-break-before always, which do you follow? How about more complicated scenarios such as: +----------+----------------------------+ | | B | | A +--------------+-------------+ | | | | | | C | D | +----------+ | | | E | | | +----------+--------------+-------------+ ...with: A { bage-break-after: always; page-break-inside: avoid; } C, D { page-break-inside: avoid; } E { page-break-before: always; } B { page-break-after: always; } ...how do you render the document? Repeat this with increasingly complex examples involving elements within the cells. The fact that these questions did not appear to have any sane answers is the reason that the working group decided that it should simply not be allowed. If you want this changed, send a detailed proposal of what the algorithm should be to www-style@w3.org.
(In reply to comment #11) I understand (and sympathize) with what you're saying. It may obviously be difficult (impossible) to handle every contingency. But what I think many of us are asking for is not an all-or-nothing approach here, but rather at-least-as-much-as-IE. In other words, while there are certainly complicated scenarios (like your side-by-side example), there are also much simpler scenarios (like simple rows within a table) - IE chooses to handle some of these simpler ones (and I'm guessing the reason they did is because a) its a fairly common business requirement and b) they could do something about it). If MZ doesn't match up to IE in this regard, that's a showstopper in terms of migrating our users to MZ.
So send a detailed version of the algorithm you want to see implemented to the www-style mailing list so that the working group can consider it and add it to CSS -- then Mozilla can implement it.
One could follow the example from the empty cell declaration and require some uniqueness over a row and require that the css will ignored when: a) the cells in a row have conflicts in their desired behaviour b) cell spans into that row or span out of that row this would in hixies example allow a pagebreak before A and after C
Furthermore as rowspans can not span across row group boundaries I believe it should be possible to define page-break-after and page-break-after for row groups and tables in a consistent way.
What about elements in the cells?
*** Bug 247461 has been marked as a duplicate of this bug. ***
IMHO 99% of web applications/layouts are based on table-layout - even quite simple websites needs several tables nested. In my case we do huge 'biurocrat' form handling with printing possiblity - now we are limited only to IE where page break is implemented inside td element. Instead of discussing how to make page-breaks in the 'artificial' case (by Ian 'Hixie' Hickson), I would suggest to make it first in the simple case, later on build final solution, especialy that this functionality is often asked for.
*** Bug 301288 has been marked as a duplicate of this bug. ***
*** Bug 279322 has been marked as a duplicate of this bug. ***
*** Bug 361256 has been marked as a duplicate of this bug. ***
I honestly cannot believe that this has been an issue for as long as it has. Why hasn't this issue been resolved? Majority of other browsers support "page-break" rules, why has Firefox/Mozilla not remedied this?
Attached file testcase from comment 0 (deleted) —
Keywords: testcase
To make solution how to break pages accurately, we should imagine that the browser just stop rendering when page-breaking element reached. Just same as it got broken connection. Draw the rest accurately, then start new page. HTML comes in flow, why just dont keep it in mind? Break the flow and resume rendering from new page, IMHO thats the solution. Hope i have helped ....7 years for this bug, my God help me
For the record, Opera 9.6 prints the test case on two pages, but Safari 3.2 and prints the test case on one page, just like Firefox. I agree with those commenters above who suggest that CSS should change to support this behavior, but I think it's correct to fix the specifications first, and then have the browsers implement the revised specification.
All/all. Blocking bug 132035.
Blocks: 132035
OS: Windows NT → All
Hardware: x86 → All
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
Depends on: 683043
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

I can't believe it's been 8 years since anyone commented on this!?

I've hit this bug/problem only recently. I have an application which sends multi-page e-mail messages. Those messages have '<div style="page-break-after: always">' elements carefully placed throughout to ensure that pagination will be correctly applied when printing the messages.

But I've discovered recently that this won't work for people who have Google gmail accounts who choose to print their messages using Firefox. Because gmail chooses to render a printable message with the message content inside a table nested within another table ... and it looks like this bug is still extant, so Firefox ignores the 'page-break-after' styling. Printing the messages from the gmail web client using Chrome or Microsoft Edge is fine; those browsers break to a new page even though the styling is embedded within nested table cells.

Is there truly no workaround for this? :-( Sadly I have no control over how Google/gmail chooses to render its print-a-mail-message HTML.

I've tested this with Firefox 41.0.1 and 67.0.4 (64-bit) on Windows 10 and 60.7.2esr (64-bit) on Linux.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 17 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: