[css-break] Clarify definition of widow and orphans.

[frivoal]

The section on orphans, widows in css-break says this:

The orphans [resp. widow] property specifies the minimum number of line boxes in a block container that must be left in a fragment before [resp. after] a fragmentation break.
[...]
If a block contains fewer lines than the value of widows or orphans, the rule simply becomes that all lines in the block must be kept together.

While it is clear to me what this is supposed to do if the block container only contains inline-level content, the meaning is less obvious when it has block level descendants.

Take this example:

<style>div {  widows: 3; }style>
<div>
  <p>
    line 1<br>
    line 2
  p>
  <p>
    line 3<br>
    line 4
  p>
div>

https://www.w3.org/TR/css-display-3/#block-container is pretty clear that block containers can either contain online inline-level boxes or block level boxes, but the terminology isn't 100% clear (as far as I can tell) about whether a block container that contains block level elements can still be said to have "line boxes in it” (indirectly, via its block level children that themselves are block containers containing inlines), or if it should be considered not to have "line boxes in it”.

1. If the above spec prose is to be interpreted as applying only to line boxes that are direct children of block containers that establish an inline formatting context, then widows:3 forbids breaks inside both

   , but does not prevent breaks between line 2 and 3:

If a block contains fewer lines than the value of widows or orphans, the rule simply becomes that all lines in the block must be kept together.

The block has no (direct) lines, there's nothing to keep together, and the break is allowed.

2. If the above prose is meant to apply to line boxes that are descendants of the block container, at any depth (but presumably within the same BFC), the the break between line 3 and 4 would be forbidden.

---

I think the spec intends the first one. If that is the case, I suggest clarifying by changing the "Applies to" line to "Block container boxes that establish new inline formatting contexts" and/or by adding the following prose: “The widows and orphan properties have no effect on block container boxes that contains only block-level boxes”.

[css-meeting-bot]

The Working Group just discussed Clarify definition of widow and orphans., and agreed to the following resolutions:

• RESOLVED: We want the interpretation to be the first option in issue 1832

The full IRC log of that discussion

Topic: Clarify definition of widow and orphans.
github: https://github.com//issues/1823
florian: I realized there was ambig. in the definition. [reads from spec]
(this is probably related to how line-clamp needs to work)
florian: The reaosn I think this is ambig is that line boxes in a block container isn't clear if they must be direct children or indirect descendants. I don't think it intends indirect. If it did if you had a div with two paragraphs with widows and you'd end up glueing them together.
florian: I think we clarify that we only mean direct children.
TabAtkins: THe usual intent is to set on a page box, correct?
fantasai: No, this is about paragraphs, not page boxes.
fantasai: The definion is about block containers with line boxes. You must have a min number of line boxes in each fragment. I thought that was clear, but if it's not we can clarify. This is only line boxes. And property inherits. If there's a block in your block that's a child. But you can break at the boundary.
fantasai: You can always say break after at a block. Usually that's not an issue because a block inside a block is sep. content.
astearns: Intent is closer to v1 in the example.
dauwhe: v2 in the example would be bad.
dauwhe: abs v1
florian: I think there are rare cases where you might want v2 but you should control that seperately.
astearns: If there is a case where you want v2 you would structure html differently.
florian: prob
dauwhe: Or the thing you're trying to fix would not be a widow.
s/a child/a child to which widows can also apply/
florian: I think we can address the rarity of v2 another time if we can resolve on meaning v1. An editor can change or I send a PR.
astearns: I'm not certain an edit is req but that may be because I"m interp in a particular way.
Bert: If florian finds it's unclear it prob is. I didn't imagine it in another way, but if florian reads it another way it needs clarification
astearns: florian you'll do a PR to fix the wording?
florian: Yes
astearns: Okay, we'll then look at wording and decide to take the change
florian: Or resolve on intent
astearns: Resolve that we want the interpretation to be the first one in your client and then you write the pull. Obj?
TabAtkins: Nope.
RESOLVED: We want the interpretation to be the first option in issue 1832

[frivoal]

Spec PR: #1864
Test PR: web-platform-tests/wpt#7685