Open Bug 132035 Opened 23 years ago Updated 2 years ago

[meta] Implement missing page-break-* CSS2.1 features

Categories

(Core :: Layout, enhancement, P3)

Product:
Core
Component:
Layout
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: schapel, Unassigned)

References

(Depends on 5 open bugs, Blocks 6 open bugs,
URL
)

Details

(8 keywords, Whiteboard: [useful information in comments 0, 54, 56])

Attachments

(7 files, 1 obsolete file)

testcase for verification
16.78 KB, text/html
Details
Screenshot of print preview showing a page-break-inside: avoid failure
12.48 KB, image/png
Details
Testcase #1, <p>'s with page-break-before:avoid
969 bytes, text/html
Details
Testcase #2, <div> with page-break-inside: avoid
1014 bytes, text/html
Details
Page-break-after:avoid testcase
11.44 KB, text/html
Details
Can do divs, paragraphs, simple tables and columns (some part of table is still broken)
24.19 KB, patch
fantasai.bugs
: review-
Details | Diff | Splinter Review
proposed testsuite (to be converted to reftests)
720.88 KB, application/x-7z-compressed
Details
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: css2
chris, you asked for it :)
Assignee: rods → karnaze
As of Mozilla RC1. Page breaks do not work (at least in Print Preview)
Page breaks use to work partially (at least the ones in bug 2400). Are you saying that no page breaks work any longer?
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.
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)
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.
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
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).
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.
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.
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.
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.
"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".
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.
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'.
Right. That's this bug.
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>
Priority: -- → P3
Target Milestone: --- → Future
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.
mass reassign to default owner
Assignee: karnaze → table
Component: Printing → Layout: Tables
QA Contact: sujay → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Hmm... Over to misc layout code, for now.... That seems like the best place.
Assignee: table → misc
Component: Layout: Tables → Layout: Misc Code
QA Contact: madhur → nobody
*** Bug 216972 has been marked as a duplicate of this bug. ***
*** Bug 195401 has been marked as a duplicate of this bug. ***
*** Bug 217144 has been marked as a duplicate of this bug. ***
*** Bug 217145 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera
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>
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.
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.
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.
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
Keywords: testcase
QA Contact: nobody → ian
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.
*** Bug 239137 has been marked as a duplicate of this bug. ***
*** Bug 210643 has been marked as a duplicate of this bug. ***
*** Bug 278251 has been marked as a duplicate of this bug. ***
Blocks: 171549
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)?
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.
Please don't add comments to the bug unless you are planning to fix it and have a patch ready.
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.
Sorry folks, but this works with Internet Exploder.
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 308970 has been marked as a duplicate of this bug. ***
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.
Summary: Support all page-break-* CSS2 properties → Support all page-break-* CSS2.1 properties
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.
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).
*** Bug 322393 has been marked as a duplicate of this bug. ***
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.
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.
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".
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;
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.
Attachment #182615 - Attachment is obsolete: true
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}.
Blocks: 137367
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.
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.
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.
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.)
(Adding CCs for possible comments re: comment 54.)
Assignee: layout.misc-code → sharparrow1
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.
Flags: wanted1.9.2?
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
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.
While waiting for the final implementation, you might be interested in this: http://bugs.debian.org/509319
Guys, please implement page-break-inside:void ! This bug is opened for 6 years already..
I assume you mean "avoid", because "void" is not a valid value for the page-break properties.
(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".
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.
@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
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!
Whiteboard: parity-opera → parity-opera [useful information in comments 0, 54, 56]
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! :-)
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.
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.
Before significant resources are expended to implement CSS3 capabilities (e.g., bug 70132), please complete the implementation of CSS2.1 capabilities (including this bug).
Safari doesn't know page-break-inside: avoid; but is fine otherwise. Adding parity.
Whiteboard: parity-opera [useful information in comments 0, 54, 56] → [useful information in comments 0, 54, 56] parity-opera, parity-Safari, parity-IE8
Depends on: 136714
Depends on: 371449
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.
Depends on: 326685
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?
This bug matches those bugs. I don't see how they can be broken into different bugs.
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.
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.
Summary: Support all page-break-* CSS2.1 properties → Implement missing page-break-* CSS2.1 features
Blocks: 495580
Flags: blocking1.9.2?
Yes, yes, yes! Make this block a release!
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Please add support for "page-break-inside: avoid".
QA Contact: ian → layout.misc-code
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!
Blocks: 521204
(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]).
For me is "page-break-inside: avoid" that is not working. Should i provide an example html testcase?
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].
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.
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.
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!
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 ;)
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.
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.
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?
Out of curiosity, what ever came of Eli's attempt?
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.
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 ;)
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.
(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.
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.
(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.)
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.
Oh God, I used 90's instead of 90s. My apologies for making such a ghastly grammar mistake.
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.
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.
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
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.
In which Gecko version has this been fixed?
It hasn't been fixed, unfortunately . If it was, we wouldn't be having a discussion here now.
Oops! I posted comment #110 in the wrong bug report.
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!
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.
(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.
Whiteboard: [useful information in comments 0, 54, 56] parity-opera, parity-Safari, parity-IE8 → [useful information in comments 0, 54, 56] parity-opera, parity-webkit, parity-IE8
Assignee: sharparrow1 → nobody
(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.
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.
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.
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.
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)
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
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.
Severity: normal → major
Severity: major → normal
PLEASE!! Include page-break-inside:avoid on that spec. Please....
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.
(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.
No longer depends on: 371449
Depends on: 683043
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
Assignee: nobody → sjohnson
Actually fantasai is planning to work on this.
Ok, sorry. I'll relinquish the assignment then. It wasn't clear to me, since comment 106 was written almost 2 years ago. :)
Assignee: sjohnson → fantasai.bugs
Quick fix hack that works surprisingly well for many cases. Tables are mostly not quite working except the most basic tables.
Attachment #558222 - Flags: review?(fantasai.bugs)
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.)
Attachment #558223 - Attachment mime type: text/plain → application/x-7z-compressed
(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...
Filed bug 685012 for page-break-inside. I'll post review comments there.
Depends on: page-break-inside
Keywords: dev-doc-needed
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 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.)
Attachment #558222 - Flags: review?(fantasai.bugs) → review-
(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.
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.
(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.
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.
Depends on: 775617
Blocks: css-break-3
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/
> 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.
Depends on: 883676
No longer depends on: 883676
Adding some bugs in current implementation as "see also" though I'd rather add them as dependencies …
See Also: → 371449, 621677, 644789
> Adding some bugs in current implementation as "see also" "See Also" usually refers to bugs in other projects.
(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?
(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).
(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/"
(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.
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.
Flags: needinfo?
(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
Flags: needinfo?
See Also: → 775618
Depends on: 1109275
See Also: 621677 →
See Also: 644789 →
Keywords: meta
Summary: Implement missing page-break-* CSS2.1 features → [meta] Implement missing page-break-* CSS2.1 features
Whiteboard: [useful information in comments 0, 54, 56] parity-opera, parity-webkit, parity-IE8 → [useful information in comments 0, 54, 56][parity-chrome][parity-webkit][parity-ie][parity-presto opera]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie, parity-opera-mini, parity-safari
Whiteboard: [useful information in comments 0, 54, 56][parity-chrome][parity-webkit][parity-ie][parity-presto opera] → [useful information in comments 0, 54, 56]
Product: Core → Core Graveyard
Is the CSS specification now implemented? If not, why is this bug relegated to "graveyard"? Has Mozilla abandoned its commitment to making its products compliant with W3C specifications?
Seems like there was a mistake made in the refactoring of some Layout bugzilla components. This wasn't intentional.
Flags: needinfo?(cam)
(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #160) > Seems like there was a mistake made in the refactoring of some Layout > bugzilla components. This wasn't intentional. I am thus restoring this to Core.
Component: Layout: Misc Code → CSS Parsing and Computation
Product: Core Graveyard → Core
Version: Trunk → unspecified
Component: CSS Parsing and Computation → Layout
Type: defect → enhancement
Flags: needinfo?(cam)

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: fantasai.bugs → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: