137367 - Implement orphans and widows

Status: NEW

(Core :: Layout: Block and Inline, enhancement, P3)

Description

[Mikko Rantalainen]

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
(http://www.w3.org/TR/REC-CSS2/page.html#break-inside) 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

[Mikko Rantalainen]

Attachment: test case: orphans and widows (print)

You might need to tweak paragraph text to make page break to hit inside a
paragraph.

Comment 2

[Boris Zbarsky [:bzbarsky, bz on IRC]]

This is simply not implemented yet.

Comment 3

[Kai Lahmann (is there, where MNG is)]

I thought I had reported this before.. hm

Comment 4

[Christine Hoffman]

Changing QA contact

Comment 5

[Moied]

Reassigning to Style System: CCS, CC'ing Madhur

Comment 6

[Brant Gurganus]

Here is a testcase: http://www.richinstyle.com/test/paged/widows.php.

Comment 7

[John A.]

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

Comment 8

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8]

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.

Comment 9

[Kevin Benton]

I have been able to reproduce this issue as well...

Comment 10

[Kevin Benton]

http://www.miamihost.net/ims/u/s1kevin/images/Ophans-Widows.jpg for sample
output of the following code

...
  div.milestones,
  div.testingreq,
  div.issues
  {
    orphans: 4;
    page-break-inside: avoid;
    text-align: left;
    widows: 4;
  }
</style>
...
<div class="issues">
  <h2>Issues</h2>
  <p>
    This section lists all the Development Plan review issues and their current
    status.
  </p>
</div>
</body>
</html>

Comment 11

[Mikko Rantalainen]

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.

Comment 12

[Zack Weinberg (:zwol)]

Orphan and widow control is also supposed to apply to individual columns in CSS3 multicolumn mode (see <http://www.w3.org/TR/css3-multicol/#filling-columns>).  That might be implementable separately from the page-break controls.

Comment 13

[Florian Bender]

This makes more sense in CSS.

Comment 14

[Chris Rebert]

This feature is already supported in all other major browsers except Firefox, according to http://caniuse.com/#feat=css-widows-orphans

Comment 15

[Gérard Talbot]

(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
> <http://www.w3.org/TR/css3-multicol/#filling-columns>). 

"
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
https://www.w3.org/TR/css-break-3/#breaking-controls

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:

http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/column-fill-balance-0xx.html

> 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

[Gérard Talbot]

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

http://test.csswg.org/suites/css21_dev/nightly-unstable/html4/chapter-13.htm#s13.3.2

Note that widows-004a test is incorrect:

http://lists.w3.org/Archives/Public/public-css-testsuite/2016Aug/0017.html

Comment 17

[Jacob Pratt]

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.

Comment 18

[Astley Chen (inactive)]

Looks like this is something we need to fix sooner or later. Jeremy, would you like to check it out?

Comment 19

[Jeremy Chen ([e-mail])]

Yeah, as the implementation status from: https://caniuse.com/#feat=css-widows-orphans shows, all other major vendors are supporting this except us. Plus, the spec is in CR already (https://www.w3.org/TR/css-break-3/#widows-orphans), so I agree this is something we need to fix.

I also notice that the usage is pretty high (according to https://www.chromestatus.com/metrics/css/popularity#orphans), 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.

Comment 20

[Astley Chen (inactive)]

Thanks for having the initial analysis of the implementation. Let's get it going once you've solved line-break webcompat issues.

Comment 21

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 22

[voracity]

Will a "please implement this" help in any way? Probably not constructive, but since I first wanted this 18 years ago and had to use Edge just recently for it, I think I'm allowed a pass this time. :)

Admittedly, Firefox's overall printing (or, more accurately, PDF-making) support has always been lacking.

Comment 23

[Gérard Talbot]

(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
http://www.w3.org/TR/css3-multicol/#filling-columns). That might be
implementable separately from the page-break controls.

I created bug 1562420 for that purpose.