17 years ago
a month ago


(Reporter: mikko.rantalainen, Unassigned)


(Depends on 1 bug, Blocks 4 bugs, 8 keywords)

Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020412
BuildID:    2002041217

CSS2 properties orphans and widows
( are not implemented or
they don't simply work. Attached test case has p {orphans: 4; widows: 4; } but
neither have any effect.

Reproducible: Always
Steps to Reproduce:
1. Open attached test case
2. Select Print or Print Preview

Actual Results:  Mozilla breaks paragraph at the end of page no matter how many
lines there is.

Expected Results:  If there would be less than 4 lines at the end of page or
less than 4 lines at the beginning of the next page the entire paragraph should
be moved to next page.

Comment 1

17 years ago
You might need to tweak paragraph text to make page break to hit inside a
This is simply not implemented yet.
Ever confirmed: true
Keywords: css2
OS: Windows 98 → All
Hardware: PC → All
I thought I had reported this before.. hm

Comment 4

17 years ago
Changing QA contact
QA Contact: petersen → moied

Comment 5

17 years ago
Reassigning to Style System: CCS, CC'ing Madhur
Component: Layout → Style System
Priority: -- → P4
Target Milestone: --- → Future

Comment 7

17 years ago
Would this affect printing of tables as well? If not, there should be an
enhancement "bug" logged for that.


16 years ago
Keywords: testcase


15 years ago
Assignee: attinasi → dbaron
QA Contact: moied → ian
Requests for new CSS properties that need to be implemented in layout should
generally live in the appropriate layout component, since that's where most of
the work is.
Assignee: dbaron → core.printing
Component: Style System (CSS) → Printing

Comment 9

14 years ago
I have been able to reproduce this issue as well...

Comment 10

14 years ago for sample
output of the following code

    orphans: 4;
    page-break-inside: avoid;
    text-align: left;
    widows: 4;
<div class="issues">
    This section lists all the Development Plan review issues and their current


Comment 11

13 years ago
I guess it doesn't make sense to support this before fixing bug 132035 (I guess this cannot be supported until page-break-inside: avoid is supported). Adding dependency.
Depends on: 132035


10 years ago
Assignee: printing → nobody
Flags: wanted1.9.2?
QA Contact: ian → printing
Whiteboard: parity-Opera, parity-IE8


10 years ago
Flags: blocking1.9.2?


10 years ago
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Orphan and widow control is also supposed to apply to individual columns in CSS3 multicolumn mode (see <>).  That might be implementable separately from the page-break controls.


7 years ago
Blocks: css-break-3

Comment 13

5 years ago
This makes more sense in CSS.
Component: Printing: Output → CSS Parsing and Computation
Component: CSS Parsing and Computation → Layout: Block and Inline

Comment 14

3 years ago
This feature is already supported in all other major browsers except Firefox, according to

Comment 15

3 years ago
(In reply to Zack Weinberg (:zwol) from comment #12)
> Orphan and widow control is also supposed to apply to individual columns in
> CSS3 multicolumn mode (see
> <>). 

In any case, the user agent should try to honor the ‘widows’ and ‘orphans’ properties.
The CSS3 multicolumn spec uses a SHOULD in such context.

A page/column/region break opportunity between line boxes is under the influence of the containing block’s break-inside, widows, and orphans properties.
CSS Fragmentation 3, section 3. Controlling Breaks

Opera 12.16 and Chrome 54+ implement widows (and, presumably, also orphans) for column boxes while Firefox 52.0a1 does not. This explains the difference of rendering of 'column-fill: auto' of topmost orange rectangle (with only single alphabetical letters) of this test:

> That might be implementable separately from the page-break controls.

Maybe a distinct, separate bug report should be created and then make it block bug 549114.

Comment 16

3 years ago
Chrome 54.0.2840.59 and Chrome 55.0.2883.11 pass the 5 orphans and 5 widows tests we have

Note that widows-004a test is incorrect:
Whiteboard: parity-Opera, parity-IE8 → parity-Opera, parity-IE8, [parity-chrome]

Comment 17

2 years ago
Is this never going to happen? It was quite literally reported 16 **years** ago, and every other browser has had support for over 4 years (per caniuse). It may not be a priority, but it certainly should be. This is a part of the CSS2 spec, and is one place where Mozilla is far behind every other engine.
Flags: needinfo?(bugs)
Blocks: 1302489
Flags: needinfo?(bugs)
Looks like this is something we need to fix sooner or later. Jeremy, would you like to check it out?
Flags: needinfo?(jeremychen)
Priority: P4 → P3
Yeah, as the implementation status from: shows, all other major vendors are supporting this except us. Plus, the spec is in CR already (, so I agree this is something we need to fix.

I also notice that the usage is pretty high (according to, though I'm not sure the number is due to raw uses or through some CSS framework which implement/use it. I suspect the reason is the latter, but this might need more inputs from web developers/evangelist.

I haven't got through the code base to figure out a detail implementation plan, but after today's brief discussion with Jonathan, we did came up with some thoughts.

1. Do we need an extra pass/extra reflow to achieve this?

Probably not. We should have all the information at the time while we detect current line is a widow/orphan. So, maybe we just need to record an/some extra information about "what line is the current line in the current block container". This should be doable by recording/annotating the first/last line in the block. Then, we could always get to decide if we should suppress a fragmentation break or not. A bit look ahead/back within the current block container might be unavoidable.

2. Does this bug depend/block the line-break property?

Not that we aware of. The implementation just need to put the fragmentation break in the right place.

3. What would the floats associated with the widow/orphan lines be affected?

Since out-of-flow elements are just placeholder children of the line container, so once the fragmentation break is changed, the whole line container would be moved to the new/correct place, and the floats should be placed accordingly.

At the moment, I'm still busy with the line-break related web-compat issues, so put this under my radar for now.
Flags: needinfo?(jeremychen)
Thanks for having the initial analysis of the implementation. Let's get it going once you've solved line-break webcompat issues.
Whiteboard: parity-Opera, parity-IE8, [parity-chrome] → [parity-blink][parity-webkit][parity-edge][parity-ie][parity-presto opera]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-blink][parity-webkit][parity-edge][parity-ie][parity-presto opera]
Comment hidden (advocacy)
You need to log in before you can comment on or make changes to this bug.