[css-overflow-4] Line-clamp and IFC

[frivoal]

Currently, line-clamp, through continue: discard, is defined not to establish and Independent Formatting Context.

In @andreubotella 's experimmental implementation of it, he found it easier to implement as creating an Independent Formatting Context. Also, in his exploration of the variant of line clamp based on hiding visibility rather than fragmentaiton, (so-called continue: collapse), he found that variant too to be simpler to implement and reason about if we can assume an Independent Formatting Context.

The original idea not to set up an IFC was not particularly driven by use cases, but rather by a theoretical argument: if we can get away without an IFC, it's more flexible, and authors can always opt into having an IFC if they need one. However, the priority of constituencies tells us to put implementation considerations ahead of theoretical concerns, so in the absence of a clear author need, we should keep it simple.

Therefore, the proposal is that, regardless of which approach we take to get to line-clamp, we do establish an IFC.

[andreubotella]

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.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] Line-clamp and IFC, and agreed to the following:

• RESOLVED: line-clamp establishes an independent formatting context

The full IRC log of that discussion

<fantasai> florian: This and the next issue are similar context
<fantasai> florian: for line-clamp we currently have a spec that uses something called 'continue: discard' which invokes fragmentation
<fantasai> florian: some discussion about an alternative approach that relies on visibility-hidden type thing instead
<fantasai> florian: awhile back we resolved to spec both and figure it out
<fantasai> florian: So Andreu has been prototyping both
<fantasai> florian: and we are developing spec for both
<fantasai> florian: We're looking at cases where the effects are accidentally differnet rather than intentionally
<fantasai> florian: Trying to harmonize them where possible
<fantasai> florian: this is one o them.
<fantasai> florian: When we initially drafted line-clamp using continue: discard
<fantasai> florian: we decided it shouldn't automatically become an independent formatting context
<fantasai> florian: it seemed possible to do so; and authors could always opt in using e.g. `display: flow-root`
<fantasai> florian: Driven by making it more nice, not by specific use cases
<fantasai> florian: Andreu found it was significantly simpler to implement if it was an independent formatting context
<fantasai> florian: so proposal is to do that instead
<fantasai> andreubotella: -webkit-line-clamp creates an independent formatting context due to creating a flexbox
<fantasai> andreubotella: For continue:discard there's also an aspect of complexity
<fantasai> andreubotella: it is assumed that every fragmentation container is an IFC
<fantasai> andreubotella: not clear what happens to floats if you have them break in the middle of a fragmentation container that isn't an IFC
<fantasai> andreubotella: Perhaps fragmentation spec that maybe all fragmentation containers should be IFC
<florian> s/making it more nice/making it more generic
<fantasai> andreubotella: When implementing it, it was clear that assuming IFC was so much easier that I didn't even attempt to not
<fantasai> andreubotella: For continue:collapse the considerations are different
<fantasai> andreubotella: I visualized that everything after clamp point should work like there's no content in the tree beyond the clamp point
<fantasai> andreubotella: That means clamped floats should not affect the outside
<fantasai> andreubotella: but what happens within the clamped function? should those floats affect each other?
<fantasai> andreubotella: in the end it was a lot easier to just not have that interaction with the outside of the line-clamp container by making it an IFC also
<emilio> q+
<fantasai> andreubotella: It could still be possible to implement, but would be significantly more complex to implement
<fantasai> andreubotella: and as Florian said, there's no significant use case for not making IFC
<astearns> ack emilio
<fantasai> iank_: It'll also be a lot easier for developers to transition to the new line-clamp because existing prefixed version establishes IFC
<fantasai> emilio: Agree
<astearns> ack dbaron
<fantasai> dbaron: The argument that you made at the end, that we don't want floats clipped by line-clamp to influence floats outside, seems like a good theoretical argument for why this is a sensible behavior that fits with everything else
<fantasai> dbaron: so I'm also in favor
<fantasai> astearns: Proposed resolution that line-clamp establishes an independent formatting context
<fantasai> emilio: When applied to blocks it creates an IFC
<dbaron> a BFC
<dbaron> (block formatting context)
<fantasai> RESOLVED: line-clamp establishes an independent formatting context
<dbaron> (I had just asked about whether we were talking about a block formatting context.)

[frivoal]

Done in dcc75ed

[andreubotella]

Tests were added in web-platform-tests/wpt#46734