Closed
Bug 24000
Opened 25 years ago
Closed 22 years ago
CSS page-break-before/after:always Support
Categories
(Core :: Printing: Output, enhancement, P2)
Core
Printing: Output
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: andreas, Assigned: karnaze)
References
Details
(Keywords: css2, testcase, Whiteboard: [Hixie-PF][eapp]PATCH)
Attachments
(3 files, 4 obsolete files)
291 bytes,
text/html
|
Details | |
887 bytes,
text/html
|
Details | |
39.12 KB,
patch
|
karnaze
:
review+
karnaze
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
I know you don't claim you've implemented CSS2, which is is ok. One reason why PDF has become so popular on the web is that HTML has ignored printing. For any serious documentation project that whishes to use HTML and has to consider printing the page-break-* property is *indispensible*, and should, IMHO, be among the first ones to be considered when moving from CSS1 to CSS2. I understand that some of the page-break-* values(!) might be somewhat more difficult to implement, but a "page-break-before: always;" to start a chapter on a new page is just like a the old form feed and should be easy to do. Is it complicated to start a new pagebox? Don't be surprised to see messages like "Your browser does not support certain printing features. Please use Browser XY for proper formatting on paper".
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Comment 1•25 years ago
|
||
Not sure if this feature is implemented... or is going to be. Will give to Pierre for disposition on this.. and if it is currently supported in Gecko .. Troy is doing the Pagination.
Assignee: dcone → pierre
Status: ASSIGNED → NEW
Comment 2•25 years ago
|
||
It's in Style already. I don't know for Layout yet. Reassigned to Troy.
Assignee: pierre → troy
Marking as REMIND. Probably won't be implemented for version 1.0
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
Comment 4•24 years ago
|
||
Pierre, if page-break-* is not going to be supported by layout, then the style system should probably not recognise the property at all, much as with the "display: marker", "content: counter()", and other such issues. I'm not sure if it matters so much with this property, however, since there is no difference between recognising it but not supporting any of it and ignoring it altogether, AFAICT.
I don't think it matters with this property if the style sytem recognises it, and so Pierre can leave the support it. That way when layout does decide to support it we don't need to get Pierre to reenable it
Comment 7•23 years ago
|
||
er, -> Future!
Assignee: troy → dcone
Severity: normal → enhancement
Status: REOPENED → NEW
QA Contact: shrir → sujay
Whiteboard: [Hixie-PF]
Target Milestone: M15 → Future
Comment 8•23 years ago
|
||
Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.
Keywords: nsbeta1
Comment 10•23 years ago
|
||
*** Bug 38164 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
Proposing for Mozilla1.0 as with the dup'd bug. This would be very useful to have.
Keywords: mozilla1.0
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
The testcase that I just attached (based on code in bug 38164) correctly adds the page breaks with IE5.
Comment 14•23 years ago
|
||
*** Bug 85279 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
I was wrong when I wrote on [2000-01-28 15:01] that page-break was in the style system already: it is parsed but it's not copied into the style context. Marked dependency on bug 72321.
Depends on: 72321
Comment 16•23 years ago
|
||
*** Bug 101960 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
What would it take to get this implemented sooner than 1.0? We have a customer requirement for this, so I would be willing to work on it myself.
Comment 18•23 years ago
|
||
Thanks for the offer... The changes in the style system are fairly easy: it's just an additional structure with the page breaks data (bug 72321 - I'll take care of it if you like). Most of the work is in Layout: Don and Rod may give you more details.
Comment 19•23 years ago
|
||
*** Bug 110185 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
taking, I would love to do this one, just don't have the time now.
Assignee: dcone → rods
Updated•23 years ago
|
Whiteboard: [Hixie-PF] → [Hixie-PF][eapp]
Major corporations depend on eapp bugs, and need them to be fixed before they can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1+
Target Milestone: Future → ---
Comment 22•23 years ago
|
||
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Comment 23•23 years ago
|
||
I would love to fix this, but at the moment the CSS parser isn't even collecting this information.
Updated•23 years ago
|
Comment 24•23 years ago
|
||
This requires substantial work and really is a feature. We will not be able to get to this for 1.0. Marking nsbeta1-
Comment 25•23 years ago
|
||
Mozila is AFAIK the only browser with CSS2 support which does _not_ implement this feature. Both Opera and IE>=5.5 supports this...
Comment 26•23 years ago
|
||
Just a little advocacy given the apparent support for Not Implementing Yet (or worse, treating it as a feature.) <p> My own employer is switching over to web technology for a lot of the reporting we give to customers. Before the web, we'd manually print the things having been faxed a request to produce such-and-such a report, or, for our "online service", used an Excel macro to populate a template worksheet with a CSV file. Theoretically, we can now move to online kludge-free reports with HTML, but our customers <i>do</i> want to print the things. <p> Well, what luck, they can! CSS2 gives us page-break-before, and Netscape 4.x always tried to keep tables on one page, so we've written the code. <p> Along comes Mozilla. Compliant with web standards, DOM Inspectors and Javascript debuggers, not to mention the other goodies be they "It's open source and platform independent kinda" to "They have this funky tab thing. You should use it, it's great." The entire programming team falls in love with it. <p> Except... except that in one critical area, it <i>isn't</i> compliant with web standards. Well, it is in the "We said which standards we were going to implement" way, but you know, and I know, and the submitter of the bug knows, and the users know, and our PHBs know, that that's a cop-out. You can't have useful printing without supporting page breaks. So the PHBs, who are having a hard enough time being convinced of the argument for browser independence in the first place, and who want to dictate exactly which browsers we use, are told that all the programmers are developing {our online web product for dynamically creating reports} using a browser that cannot even print our reports correctly, not because it has a minor bug, not because we haven't used it's particular workaround, but its implementation of CSS2 isn't as complete as Microsoft's is. <p> This "feature" is critical for serious business use of HTML and Mozilla. It's so obviously a standard that <a href="http://developer.netscape.com/evangelism/docs/technotes/xref/dom-css-style-object/ ">DevEdge</a> lists it as best practice for DOM NS6 and IE! <p> If you can't implement it, could you at least look into some work-around, even a non-standard <break> tag or something? Even implement the Netscape 4.x tables hack? It might be ugly and might force us to put in some "if browser == mozilla" code, but right now, that would be an improvement. <p> Thanks, and whatever the rant above, let it be known that my collegues and I really, really, appreciate what you're doing. Mozilla is a fantastic browser - as I said above, it's the programmers' browser of choice where I work.
Updated•23 years ago
|
Priority: P3 → P2
Target Milestone: mozilla1.1 → Future
Assignee | ||
Comment 27•23 years ago
|
||
I'm taking the bug and will attach a patch shortly that uses rods' idea of creating dummy frames for page breaking. This will work for page-break-before:always and page-break-after:always. The other properties and values require much deeper layout changes that probably will not happen until long past m1.0.
Assignee: rods → karnaze
Assignee | ||
Comment 28•23 years ago
|
||
This patch hasn't been tested much and there are a few things that still need to be done besides further testing - (1) the logic of creating page break frames in nsCSSFrameConstructor.cpp::ConstructFrame needs to copied to other custom construction methods (e.g. ConstructTableFrame), (2) the style system hacks should be removed and replaced with a new style struct; although if this weren't done, I don't think the 2 added data members on nsCSSDisplay would be that bad, assumming that nsCSSDisplay is not long lived like nsStyleDisplay.
Comment 29•23 years ago
|
||
Marking nsbeta1+ for supporting: page-break-before:always and page-break-after:always
Updated•23 years ago
|
Target Milestone: Future → mozilla1.0
Comment 30•23 years ago
|
||
Just wanted to add my appreciation for you upping the priority on this issue, it's definitely welcome!
Assignee | ||
Comment 31•22 years ago
|
||
In this patch tables handle page breaks internally. There is still a problem with the style system hacks and style context sharing.
Attachment #71320 -
Attachment is obsolete: true
Assignee | ||
Comment 32•22 years ago
|
||
Assignee | ||
Comment 33•22 years ago
|
||
Attachment #73255 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [Hixie-PF][eapp] → [Hixie-PF][eapp]PATCH
Assignee | ||
Comment 34•22 years ago
|
||
Revised to include some omissions caught by attinasi. This patch (as does the previous one) also fixes the problems mentioned in comment #31, thanks to attinasi.
Attachment #74243 -
Attachment is obsolete: true
Comment 35•22 years ago
|
||
Comment on attachment 74265 [details] [diff] [review] revised patch with reviewer's suggestions r= alexsavulov
Comment 36•22 years ago
|
||
Comment on attachment 74265 [details] [diff] [review] revised patch with reviewer's suggestions I think that the eCSSProperty_page_break_inside cases should either be put in, ore removed (commented at least) - there seems to be mixed attention given to that property. GetDesiredSize and Reflow should ASSERT/PRECONDITION aPresContent is non-null What does + // work around block bugs mean in GetDesiredSize? Shouldn't PageBreakFrame assert that we are in paged- mode (printing)? Anyway, those are minor points - sr=attinasi
Attachment #74265 -
Flags: superreview+
Assignee | ||
Comment 37•22 years ago
|
||
Encorporates all of attinasi's suggestions except the 1st one, which he agrees is ok to ommit.
Attachment #74265 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #74442 -
Flags: superreview+
Attachment #74442 -
Flags: review+
Comment 38•22 years ago
|
||
Comment on attachment 74442 [details] [diff] [review] revised patch with additional reviewer's suggestions a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74442 -
Flags: approval+
Comment 39•22 years ago
|
||
+ CHECKDATA_PROP(nsCSSDisplay, mBreakBefore, CHECKDATA_VALUE, PR_FALSE), // temp fix for bug 2400 Could we please fix that comment to have the right bug number?
Assignee | ||
Comment 40•22 years ago
|
||
The patch is in. I'll fix the comment.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → FIXED
Comment 41•22 years ago
|
||
Suggested change: s/temp fix for bug 2400/temp fix for bug 24000 ("CSS page-break-* Support ?")/
Comment 42•22 years ago
|
||
Is this fixed for all page-break-* properties now, or is there a bug to track the real fix (post 1.0)?
Assignee | ||
Comment 43•22 years ago
|
||
Changing summary to restrict to page-break-before/after:always. Someone can open a new bug for full page break support, but it will probably not be fixed for a long time.
Summary: CSS page-break-* Support ? → CSS page-break-before/after:always Support
Comment 44•22 years ago
|
||
I've opened bug 132035 for support of all CSS2 page-break-* properties.
Comment 45•22 years ago
|
||
Can anyone file a bug to get some tests into the printing tests used for the smoketesting ?
Comment 46•22 years ago
|
||
Andreas this is fixed now..can you verify this in latest build ? thanks...let me know if this is working for you now...
You need to log in
before you can comment on or make changes to this bug.
Description
•