Open Bug 137367 Opened 19 years ago Updated 1 month ago

Implement orphans and widows

Categories

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

enhancement

Tracking

()

Future
Webcompat Priority ?

People

(Reporter: mikko.rantalainen, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

(8 keywords)

Attachments

(1 file)

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.
You might need to tweak paragraph text to make page break to hit inside a
paragraph.
This is simply not implemented yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: css2
OS: Windows 98 → All
Hardware: PC → All
I thought I had reported this before.. hm
Changing QA contact
QA Contact: petersen → moied
Reassigning to Style System: CCS, CC'ing Madhur
Component: Layout → Style System
Priority: -- → P4
Target Milestone: --- → Future
Would this affect printing of tables as well? If not, there should be an
enhancement "bug" logged for that.
Keywords: testcase
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
I have been able to reproduce this issue as well...
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>

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
Assignee: printing → nobody
Flags: wanted1.9.2?
QA Contact: ian → printing
Whiteboard: parity-Opera, parity-IE8
Flags: blocking1.9.2?
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 <http://www.w3.org/TR/css3-multicol/#filling-columns>).  That might be implementable separately from the page-break controls.
Blocks: css-break-3
This makes more sense in CSS.
Component: Printing: Output → CSS Parsing and Computation
Component: CSS Parsing and Computation → Layout: Block and Inline
This feature is already supported in all other major browsers except Firefox, according to http://caniuse.com/#feat=css-widows-orphans
(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.
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
Whiteboard: parity-Opera, parity-IE8 → parity-Opera, parity-IE8, [parity-chrome]
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: 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.
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]

(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.

Webcompat Priority: --- → ?

Note that widows-004a test is incorrect:

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

You need to log in before you can comment on or make changes to this bug.