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