[css-overflow-4] Line-clamp and IFC about csswg-drafts HOT 1 OPEN

To expand on the difficulties found when trying not to establish an IFC:

• The main feature of continue: discard is that it turns a box into a fragmentainer. The other existing fragmentainers are always an IFC from the perspective of the outside (not of the content flowing inside them): for multi-column (and regions) this is explicitly specified as such, and for paged media this is necessary because there is no content outside of the fragmentainer.

  While this precedent by itself is not a reason to force continue: discard to establish an IFC, it means that existing layout engines might implement fragmentation in ways that assume an IFC (as Chromium does). And the possibility that fragmentainers are not always IFCs would open a number of spec questions that would need to be answered (e.g. what happens when a non-IFC continue: discard contains a float with a break inside it? Would it affect the positions of floats and the clearance of boxes in the same BFC but outside the fragmentainer?)

• For continue: collapse, the main difficulty is floats. The way I conceptualize this variant as working, the rendered result should behave as if none of the content after the clamp point in the layout tree existed (modulo the ellipsis). Therefore, floats before the clamp point should be able to affect the position of floats and the clearance outside of the continue: collapse container, but floats after the clamp point should not.

  However, the geometry of boxes after the clamp point should be queryable from JS APIs. If we want that to give any kind of meaningful result, then the positioning of floats and the clearance of boxes after the clamp point should depend on the floats before and after the clamp point.

  So while I don't think this is a no go for the Chromium implementation, it certainly adds complexity that might not be needed for any actual use cases.

from csswg-drafts.