Fragmenting (continue: collapse) line-clamp containers #12812
Description
Should line-clamp containers fragment, and how? The continue: discard variant was built on fragmentation, and it defines what happens when it's contained in a fragmentainer. But what about continue: collapse?
In principle, the spec text for continue: collapse doesn't give any reason for fragmentation to not apply. However, since this variant of line-clamp was meant to minimize the implementation differences with the legacy implementations while still achieving a good and interoperable result, it's worth looking at how this works for -webkit-line-clamp in various browsers; both when you put a line-clamp container inside a multicol, and when you try to make an element a line-clamp and multicol container at the same time.
In WebKit, a line-clamp container inside a multicol works just as you'd expect: it properly fragments, and properly keeps the line-clamp state across fragments. This is as expected, since apparently the layout engine in this case still doesn't layout fragments individually, but instead the output of the layout phase is sliced into fragments. Setting overflow: hidden on the line-clamp container doesn't make it monolithic.
If you try to make an element both a line-clamp and a multicol container in WebKit, however, it will just be a line-clamp container that doesn't fragment by itself. This is because display: -webkit-box in the presence of -webkit-line-clamp still behaves like a legacy flexbox, and the columns properties only work on block containers.
In Firefox, if you set overflow: hidden on a line-clamp container (as it often happens), it will become monolithic. The fragmentation spec allows elements with overflow: hidden and a non-auto logical height to be monolithic, and while this doesn't exactly apply here, the sizing behavior of line-clamp can be seen as setting a used logical height based on the content. Without overflow: hidden, though, each fragment seems to have its own line count, and each seems to clamp separately.
Meanwhile, if you set the columns property to a line-clamp container in Firefox, it will seemingly become a multicol container and not a line-clamp container. This is evidenced by the fact that no clamp will happen, even if the number of lines in each fragment is higher than the -webkit-line-clamp value.
In the case of Chromium, line-clamp containers inside a multicol are treated as monolithic. However, a line-clamp container with columns properties will fragment, apparently due to a bug. In this case, the fragments have their own separate line count and clamp individually, similar to Firefox. (For what's worth, Chromium made line-clamp monolithic to fix an infinite recursion bug, but I can't reproduce that bug anymore when I make it non-monolithic.)
In principle, the issues with Firefox and Chromium not properly propagating the line count across fragments are not insurmountable; but it'd be definitely easier to fix them by making line-clamp containers monolithic.
For what's worth, with respect to making an element a line-clamp and multicol container at the same time, the current spec seems to agree with Firefox's behavior. The specified display: -webkit-box (if any) has its computed value set to display: flow-root, so now the columns properties apply. But now the box is a multicol container, and the spec text for continue: collapse says that in that case, it behaves like auto. So you end up with a multicol container, and the block BFC established by the column boxes isn't a line-clamp container.