[csswg-drafts] [css-overflow] Floats and line-clamp (#12665)

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

== [css-overflow] Floats and line-clamp ==
In https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-3206198816, a question came up about the behavior of floats with `line-clamp`.

In all legacy implementations of `-webkit-line-clamp`, there is only clamping by a number of lines, the line-clamp container's height is set depending on the position of the bottom edge of the line to clamp after. Any lines after that are still rendered, which is why `overflow: hidden` is needed.

Floats don't change this behavior, so it's perfectly possible to have a float whose in-flow position is before the clamp point, but whose height extends past it. The float will overflow the line-clamp container, and `overflow: hidden` will apply as normal.

Webkit is special here in that it allows clamping inside floats. It seems like the line clamp state will propagate into independent formatting contexts, and allows clamping inside them, even in tables. I think this is a side effect of the fact that in Webkit, `-webkit-line-clamp` containers are still legacy flexboxes, and the line clamp state needs to propagate to the flex items, which are IFCs. The current spec doesn't allow clamping inside IFCs, and since other browser engines don't have this behavior, it's probably not worth worrying about.

However, for `line-clamp` and spec-based implementations of `-webkit-line-clamp`, content after the clamp point would not be rendered, regardless of the value of `overflow`. So how does this affect floats?

Rather than setting the line-clamp container's height depending on the clamped line, the current spec text says:
> If a block container contains a clamp point, within itself or in any of its descendants, its [automatic block size](https://drafts.csswg.org/css-sizing-3/#automatic-block-size) will not take into account any invisible boxes. This also applies for the line-clamp container itself.

That is to say, any boxes that are hidden are treated as if they weren't there for the size calculation. However, a side effect of this is that, since the line-clamp container is an independent formatting context, non-hidden floats add clearance. This increases the automatic size of the line-clamp container so that all non-hidden floats fully fit.

This also has an effect on clamping by height, since the clamp point is chosen depending on the size the line-clamp container would have if we clamp there. Therefore, if there's a float that extends past the container's `max-height`, the only option is to clamp before the float even starts.

---

I personally like the fact that the size of the line-clamp container behaves just like the size it would have if the hidden elements weren't there. But I understand that this behavior for floats is very likely unintuitive:

![Image](https://github.com/user-attachments/assets/6ab67665-5e7a-4720-907b-459b9f175352)

![Image](https://github.com/user-attachments/assets/e3985fef-8cc7-40d5-a727-12c2667c83a2)

So, should we instead let floats overflow the line-clamp container?

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


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

Received on Wednesday, 27 August 2025 17:31:33 UTC