Open Bug 137367 Opened 22 years ago Updated 13 hours ago

Implement orphans and widows

Categories

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

enhancement

Tracking

()

Future
Webcompat Priority P3

People

(Reporter: mikko.rantalainen, Unassigned)

References

(Depends on 1 open bug, Blocks 4 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.

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!

Webcompat Priority: ? → P3

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 "CSS 2.2" filter.

Sebastian

Severity: normal → S3

Jonathan, is the analysis by Jeremy and you from comment #19 still correct?
I had a quick conversation with Emilio about the line-clamp, lately, which seems related regarding fragmentation and line counting. And he said, that the implementation of line-clamp requires a lot of changes in the fragmentation logic. So I assume this is the case here, as well. Though, on the other hand, once implemented, both could benefit from that.

For what it's worth, the usage statistics for orphans and widows are more than 3%.

Sebastian

Flags: needinfo?(jfkthame)

Yeah, I don't think much has changed relating to this. I do think it would be good to work on this sometime soon.

I suspect this isn't as complex as line-clamp, since it won't involve changing how fragmentation behaves. It's just about whether we're allowed to break at a given place or not, but what "breaking" means doesn't change.

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.