[css-overflow-4] [css-break] How does `widows` and similar properties affecting fragmentation interact with `continue: discard`?

[andreubotella]

<div style="continue: discard; height: 4lh; widows: 2;">
  Line 1<br>
  Line 2<br>
  Line 3<br>
  Line 4<br>
  Line 5
</div>

continue: discard makes the div into a fragmentainer and discards any content after the first break, forced or unforced. Since the height is 4lh, "Line 5" is certainly after the first break, but what about "Line 4"? If following fragments were not discarded, "Line 4" would be after the unforced break in order to avoid a single widow in the second fragment, but should that work the same if the second fragment is discarded?

The spec text for continue: discard does not say anything about how an unforced break is computed, so it is reasonable to assume that the same behavior applies as for non-discarding fragmentation. On the other hand, since the spec text for widows talks about lines in a fragment, you could see this as not applying to discarded fragments.

One thing to note is that the inital value of widows is 2, so it might come as a surprise to developers that the clamping sometimes happens one line earlier than it should, depending on the number of lines in the continue: discard box. And importantly, there would be no indication anywhere that it's widows that is causing this effect. (It certainly came as a surprise to me when working on my in-progress implementation of continue: discard in Chromium, taking me a while to realize it was not a bug in my layout code.)

[andreubotella]

cc @frivoal @mstensho

[mstensho]

And similarly for orphans, actually...

<div style="continue: discard; height: 4lh; orphans:2; widows:1;">
  Line 1<br>
  Line 2<br>
  Line 3<br>
  <div>
    Line 4<br>
    Line 5
  </div>
</div>

I agree that it's somewhat surprising for orphans and widows to have an effect here. By the way, Chromium has received numerous bug reports over the years on orphans / widows being honored at all in multicol, especially with tall 100% wide images or inline blocks where authors expect a perfect break opportunity between every line.

That said, as long as continue:discard is defined as establishing a fragmentation container, what else can we do?

Is continue:discard mostly a way of defining line-clamp [1], a shorthand? In that case, maybe just define that line-clamp != none as also setting orphans and widows to 1?

[1] https://www.w3.org/TR/css-overflow-4/#line-clamp

[bfgeek]

Yeah this makes me think that the @emilio 's solution is more desirable still. Fragmentation has lots of side-effects which aren't desirable for line-clamping.

[frivoal]

One possible solution to this is to have the line-clamp shorthand set window and orphans to 1.

[frivoal]

The spec now says:

Note: The widows, orphans, and break-inside properties do not affect the position of the forced region break introduced by the max-lines property.

I think it would be fine to have a Note indicating that in the continue:collapse variant, these are not taken into account (since there is no normative text that would cause them to be), but in the continue: discard, I think this needs to be more than a Note, and we need something normative, because otherwise, normative text means that widows, orphans, and break-inside would apply.

First, a question: why include "break-inside" in the list of excluded properties? Unlike widows and orphans, it's initial value is not problematic. If it is in effect, that means an author set it. Shouldn't we honor it?

Either way, I think we can accomplish the desired effect in two ways:

• Just state that they don't apply, right there in the spec. In effect, just keep the text of that note, but make it normative.
• (leave break-inside alone and) change the initial values of the widows and orphans properties to become auto, which does the same thing as now (i.e. 2) in most contexts, but has no effect in this particular case. That way, if authors do want them to apply, they can set an explicit value.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] [css-break] How does `widows` and similar properties affecting fragmentation interact with `continue: discard`?, and agreed to the following:

• RESOLVED: The region break set by line-clamp ignores widows/orphans

The full IRC log of that discussion

<fantasai> s/Topic/Subtopic/
<fantasai> s/Topic/Subtopic/
<fantasai> s/Topic/Subtopic/
<fantasai> andreubotella: Here's an implementation of continue:collapse. You can see when the height is reduced to zero, the lines get hidden one by one.
<fantasai> andreubotella: continue:discard is the previous version of this, which was handled with fragmentation
<fantasai> andreubotella: You don't see the same thing, you see that first two lines are hidden together
<fantasai> andreubotella: If you only leave space for first line, both discarded.
<fantasai> andreubotella: Reason for this is 2 properties called widows/orphans
<fantasai> andreubotella: Names are typographical terms, somewhat confusing, maybe we need to rename? But that's off-topic
<fantasai> andreubotella: They control how many lines can be by themselves at the start or end of a fragment
<fantasai> andreubotella: The default value is 2, meaning a single fragment isn't allowed
<astearns> fantasai: do you have an incorrect assumption?
<astearns> fantasai: widows shouldn’t affect the first fragment
<fantasai> fantasai: There's no breaking opportunity between the start of the container and its first line box
<fantasai> fantasai: You will always place at least some content
<astearns> ack fantasai
<fantasai> florian: If you have a 2-line paragraph, and a many line paragraph ... in fragmentation it is what you want, but in this case maybe not
<fantasai> florian: My suggestion is that line-clamp also sets widows/orphans to 1.
<fantasai> florian: Otherwise if there's room for 3 lines, and you only get 2, it will be surprising
<astearns> ack dbaron
<fantasai> andreubotella: My suggestion was to make line-clamp ignore widows/orphans
<fantasai> dbaron: Principle is that you always place something.
<fantasai> dbaron: One reason it exists is not getting into an infinite loop when all fragmentainers are identical.
<fantasai> dbaron: In this case, you have to place something.
<fantasai> dbaron: In context where fragmentainers are not all identical, you may or may not want that principle.
<fantasai> dbaron: But I think we're coming to another solution here...
<fantasai> florian: Andreu's and mine would do the same thing by default, but mine allows authors to set things so that they do take effect, whereas in Andreu's there's no option
<fantasai> astearns: Chair hat off, I'm a little more comfortable with just defining interaction between the properties, rather than having one property set another...
<fantasai> florian: I'm split here. Andreu's version is less magic
<fantasai> florian: If you're doing a very small height in which you're line-clamping, but if people are doing it on a bigger chunk of content, room for 10 lines
<fantasai> florian: maybe in that case would want to have widows and orphans take effect
<fantasai> florian: Completely suppressing most of the time might not be the right call
<astearns> fantasai: suppose you have clamp that’s large and you are fragmenting?
<astearns> fantasai: there you’d want widows to take effect
<fantasai> andreubotella: Question of whether line-clamp container should fragment. It's very buggy and non-interop in browsers.
<fantasai> andreubotella: If we allow these containers to fragment, then probably continue:discard, rather than block effects of this property, it should say that they don't apply for setting the region break
<fantasai> florian: Ok, my earlier pref for setting to 1 rather than ignoring, is not an objection. I'm now on the fence, see arguments both ways.
<fantasai> florian: Long-term, if we really need an opt-in, we can create one.
<fantasai> astearns: Let's go with andreubotella's suggestion for now. It's the least we can do to fix this particular issue.
<fantasai> astearns: We can make that interaction more complicated in the future if we need to
<fantasai> PROPOSED: The region break set by line-clamp ignores widows/orphans
<fantasai> RESOLVED: The region break set by line-clamp ignores widows/orphans