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]]

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:]

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.

Comment 25

[Gérard Talbot]

Note that widows-004a test is incorrect:

Several months ago, someone (can't remember who) corrected accordingly widows-004a test.

Comment 28

[rhand_mbugs]

I see that this issue is now 19 years old. I see at https://caniuse.com/?search=orphan that all browsers have been supporting widows and orphans for quite some time now expect for Firefox. I also see at https://drafts.csswg.org/css-break-3/#widows-orphans that widows and orphans are now part of the "CSS Fragmentation Module Level 3 Breaking the Web, one fragment at a time Editor’s Draft, 6 February 2021" I see at https://developer.mozilla.org/en-US/docs/Web/CSS/orphans that they now recommend to extends orphans to apply to any type of fragment, including pages, regions, or columns in the Candidate Recommendation in the CSS Fragmentation Module Level 3. This besides CSS Level 2 revised on fragmentation.

This expansion of fragmentation and the option to use orphans and widows on columns and other elements would really help out a lot of people setting up content properly. CSS Columns has been something we have been wanting to work newspaper style with interconnected columns for a long time, but we miss solid control on column endings. With better support for orphans and widows and better support for fragmentation in general we would be really helped.

Firefox as a forefront figher should help push on the web and make working with content as pleasurable as possible. Now I see Chrome and Edge further ahead while this had never been the case in the past. Please let's forge on!

Comment 30

[Sebastian Zartner [:sebo]]

Just a side note: widows and orphans are the only two CSS properties of CSS 2 that aren't supported by Gecko yet. See https://css3test.com and select the "All" filter.

Sebastian