[css-break-4] orphans and widows for fragmented monolithic replaced elements

[bernhardf-ro]

This topic has been split from #3404 at the request of @fantasai

When fragmenting monolithic replaced elements, e.g. images, it would in many cases be useful to have functionalities similar to orphans and widows, to avoid splitting off too small parts at the beginning or end.

Our current approach is actually using the orphans and widows properties, multiplying their values with the used line-height of the image box, causing breaks to be avoided or happen earlier, as in text.

[fantasai]

Agenda+ to see if adding a <length> value to the widows/orphans properties would be an acceptable way to solve this, or if we should do something else.

[faceless2]

It seems reasonable to me. Evaluating a length in a non-replaced context, we would presumably convert it back to a regular number with Math.ceil(length / lineheight) where lineheight is the height of the block container that orphans or widows would apply to.

[bernhardf-ro]

We like the idea of a <length> value. However, we would prefer it to be applied via new properties, like orphan-/widow-size. Those should not be inherited, unlike orphans and widows. Then they could be applied to any block container, preventing breaks inside areas at the beginning or end with the specified height.

This would, for example, cover the use case that sections/chapters should not start in the bottom 7cm of a page, for which our customers currently require JavaScript.

<percentage> values would also be useful, when resolved against the height of the fragment container (or to 0 if that height is not definite).

The precision of the used <length> should not be limited to multiples of line-height. If that is required the lh unit can be used.

edit: Changed to use separate properties for <length> value, as our use cases require them to not be inherited, unlike orphans and widows.

[css-meeting-bot]

The CSS Working Group just discussed orphans and widows for fragmented monolithic replaced elements, and agreed to the following:

• RESOLVED: work on a mechanism to control where slicing is allowed as a length from either side of the monolithic element

The full IRC log of that discussion

<Rossen_> Topic: orphans and widows for fragmented monolithic replaced elements
<Rossen_> github: https://github.com//issues/3405
<fremy> fantasai: this is a feature request for fragmentation level 4
<fremy> fantasai: it would be nice to control widow/orphan in a more monolithic way
<fremy> fantasai: it would be a length instead
<fremy> fantasai: and thus cannot inherit so we need a new property
<fremy> fantasai: it would say how much space you need on the page to accept to start flushing in the container
<florian> q+
<jensimmons> q-
<Rossen_> ack jensimmons
<fremy> fantasai: proposal would be widow-length or something
<fremy> faceless2: I don't think the name should be widow/orphan its a different concept
<fantasai> s/widow-length/widow-something: <length>/
<Rossen_> ack florian
<fremy> florian: maybe I misrember but I think we are not supposed to split monolithic elements at all
<fremy> florian: so the default value should be 100% right?
<Rossen_> q?
<fremy> florian: (split only happens if you cannot fit)
<fremy> fantasai: we want to control that
<fremy> fantasai: and that is the next issue
<fremy> florian: why a different toggle?
<fremy> florian: if you have 100%
<myles> q+
<fremy> fantasai: yes, but break-inside is more reasonable to find for authors
<fremy> florian: yes, that's true
<fremy> Rossen_: are we discussing accepting the proposal?
<fremy> myles: is my understanding correct to say that they don'
<fremy> myles: t like when 3px of their image appears at the end of a page
<fremy> myles: and the rest gets displayed on the next page?
<fremy> fantasai: yes
<fremy> myles: ok
<Rossen_> q?
<fremy> Rossen_: any other thought?
<Rossen_> ack myles
<fremy> florian: I am not sure it's a different than the break-inside thing
<jfkthame> q+
<fremy> florian: for example on some images there might be only three points where you want to break
<tantek> interesting, the image breaking equivalent of soft-hypens
<fremy> Rossen_: is that a reason to hold off on the proposal?
<fremy> florian: I think it's weird to have a toggle for something
<fremy> florian: that we can't do yet
<Rossen_> ack jfkthame
<fremy> fantasai: we slice if it doesnt fit
<fremy> florian: but we might want different if it is forced or not
<myles> q+
<fremy> JonathanNeal: seems to be refinements of break-inside to me
<florian> +1 to jfkthame
<fremy> JonathanNeal: so sub-properties of break-inside
<Rossen_> ack fantasai
<faceless2> q+
<fremy> fantasai: we don't control where you can break in break-inside
<fremy> fantasai: break-inside, so far, is only whether you can break or not
<Rossen_> ack myles
<fremy> fantasai: I think this is a good separation to have
<fremy> myles: also, there are two values, bottom and top
<fremy> myles: if the sum is bigger than 100%, what happens?
<fremy> fantasai: can't break anywhere
<Rossen_> q?
<faceless2> q-
<fremy> florian: but then you are back to the case where you have to differentiate whether you are in the normal case or the error case
<fremy> fantasai: if needed you slice wherever
<fremy> myles: in the case I described, we would not slice though, right?
<fremy> fantasai: you slice
<fremy> myles: I am confused
<fremy> myles: let me restate
<myles> you have an image that's 100px tall
<Rossen_> q?
<myles> the fragmentainer is 75px tall
<myles> and you use both of these properties to say "don't break within 80px of the top and don't break within 80px of the bottom"
<myles> <fin>
<myles> this would overflow, right?
<fremy> Rossen_: (btw we only try to decide if we want to work on this, don't need to have all the details nailed in)
<fremy> fantasai: several things happen
<fremy> fantasai: let's start with 120px fragmentainer
<fremy> fantasai: in that case, we move the image to the next fragmentainer
<fremy> fantasai: now, if the fragmentainer is smaller
<fremy> fantasai: we are going to ignore the restrictions
<fremy> fantasai: so we do slice at 75px
<fremy> fantasai: though in theory, the ua is allowed to break anywhere
<fremy> fantasai: there is a further proposal to add toggles for this, but this would remain an opt-in
<fremy> fantasai: by default we make sure all the content is rendered
<fremy> myles: got it
<fremy> Rossen_: so, do we feel we want to pursue this?
<fremy> Rossen_: and add to break-4
<fremy> Rossen_: any objection?
<fremy> RESOLVED: work on a mechanism to control where slicing is allowed as a length from either side of the monolithic element