[css-overflow-4] Draft spec for continue: collapse (#7708)

[andreubotella]

No description provided.

[bfgeek]

@emilio - Does this look reasonable to you?

[andreubotella]

Before now, this PR allowed clamping between any two blocks, to make it closer to the continue: discard behavior, but in hallway conversations in TPAC we agreed that having it clamp to the last line before clamp, even if there are lineless boxes after it that will still fit, was a better behavior. I just updated the spec text to reflect this.

[tabatkins]

but in hallway conversations in TPAC we agreed that having it clamp to the last line before clamp, even if there are lineless boxes after it that will still fit, was a better behavior

In particular, the argument was that auto clamping should be equivalent to the largest <integer> clamp that avoids overflow; it's weird if auto actually lets you include an amount of content between two <integer> values, and thus can't be reproduced directly.

[frivoal]

This seems mostly good. I've made a few small suggestion for normative changes, and more suggestions for editorial changes (most of which are about source formatting).

Most of the remaining issues are orthogonal to this PR, so I think we can merge first and keep working on those later, as soon as the comments on this PR are addressed.

[frivoal]

I'm ok with that, but I think this has been controversial, with some advocating that the displaced content be dropped / invisible instead, in order to avoid that inserting the ellipsis would cause an extra layout pass. Should we open a separate issue to discuss that aspect?
Or maybe this is unavoidable due to bidi processing of the ellipsis, which means we have to relayout anyway?

[andreubotella]

The bidi processing of the ellipsis would make it unavoidable to relayout at least that line, but not necessarily the lines after it. But if we only do that line, then there could be inline elements that end up falling out of the layout if they now don't fit in the line with the ellipsis.

[frivoal]

@tabatkins , for your comment in #10816 (comment), I'd suggest following up in #10868, because that aspect exists before this PR. The text of the spec may need to change depending on where we land on that issue (and others), but this PR isn't changing it, so I think we should take one problem at a time.