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
274 bytes, 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?

    
  
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: