[csswg-drafts] Fragmenting (`continue: collapse`) line-clamp containers (#12812)

andreubotella has just created a new issue for https://github.com/w3c/csswg-drafts:

== Fragmenting (`continue: collapse`) line-clamp containers ==
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 `display: -webkit-box` (if present) becomes a `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.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12812 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 16 September 2025 12:37:34 UTC