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

The CSS Working Group just discussed `[css-overflow] Floats and line-clamp`, and agreed to the following:

* `RESOLVED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> andreubotella: For continue:collapse, defiinition says if block container contains a clamp point, automatic size will not take into account the content after the clamp point<br>
&lt;fantasai> andreubotella: What does that mean for the line clamp container? It is an independent formatting context, so it is subject to float clearance<br>
&lt;fantasai> andreubotella: If you have a float that is not hidden, it will add clearance to the line clamp container<br>
&lt;fantasai> andreubotella: This is not always what authors expect<br>
&lt;fantasai> andreubotella: In this case, changing webkit-line-clamp to lines 3 or 4, it means float would make the box taller than you would expect by the lines<br>
&lt;fantasai> andreubotella: but if you're clamping by height, the moment you reach the end of the float and you try to push the height upwards, then you would be clamping up to the line before the float<br>
&lt;fantasai> andreubotella: the float is anchored to line 3<br>
&lt;fantasai> andreubotella: I like the consistency with regular sizing, but this is not intuitive<br>
&lt;florian> q+<br>
&lt;fantasai> andreubotella: It is also different from behavior you would get with continue:discard, because the float would fragment<br>
&lt;astearns> ack florian<br>
&lt;fantasai> florian: Behavior is surprising, but consistend and explainable<br>
&lt;fantasai> florian: If we try to do better, might be able to say that a float that grows the box by adding clearance is treated as invisible, and you remove the float<br>
&lt;fantasai> florian: Don't remove floats in general, because they can cause content to wrap differently<br>
&lt;fantasai> florian: but if it's increasing height of container, then remove it<br>
&lt;fantasai> florian: but then that would change the wrapping of earlier lines..<br>
&lt;fantasai> florian: so maybe put a dummy float?<br>
&lt;fantasai> florian: Anyway, current behavior is not terrible.<br>
&lt;fantasai> andreubotella: I'm worried about implementability even if it doesn't cause lines to wrap differently<br>
&lt;florian> q+<br>
&lt;astearns> ack dbaron<br>
&lt;fantasai> dbaron: I'm not sure how much the underlying mechanism here is related to fragmentation<br>
&lt;fantasai> florian: meant not to<br>
&lt;fantasai> dbaron: but even if it doesn't, thinking about it analogously might help<br>
&lt;fantasai> dbaron: The way floats fragment is not well-specified, and probably not interoperable across engines<br>
&lt;fantasai> dbaron: but my memory of how it works in Gecko, you can push the float to the next fragment without pushing the lines adjacent to it<br>
&lt;fantasai> dbaron: In some cases you can also fragment the float<br>
&lt;fantasai> dbaron: that might not make sense here<br>
&lt;fantasai> dbaron: so idk how well analogy to fragmentation works<br>
&lt;astearns> I think fragmenting floats is not terribly interoperable<br>
&lt;fantasai> dbaron: but the other behavior I could imagine is the float goes away at a shorter height in the first case, but lines do what you expect simultaneously<br>
&lt;fantasai> dbaron: that said, idk how hard it is to implement<br>
&lt;fantasai> andreubotella: I worry it's not easy, but I will have to check<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> fantasai: I think that second case seems surprising<br>
&lt;astearns> fantasai: if we did fragment it would be more in line with author expectations<br>
&lt;astearns> fantasai: where we introduce the line clamp could be treated as a frag break<br>
&lt;fantasai> andreubotella: for continue:collapse, it doesn't work based on fragmentation<br>
&lt;fantasai> andreubotella: it just sizes the container based on the size it would have if you ignored the hidden content<br>
&lt;fantasai> andreubotella: and floats can be either shown or hidden<br>
&lt;astearns> ack florian<br>
&lt;fantasai> florian: So based on this, my suggestion is to close no change<br>
&lt;fantasai> florian: "we're doing collapse, but these advanced cases want fragmentation", in that case use fragmentation<br>
&lt;fantasai> florian: But that assumes we'd actually define and implement continue:discard.<br>
&lt;fantasai> florian: But I worry we'll end up with something as complicated as fragmentation.<br>
&lt;Rossen4> Zakim, start meeting<br>
&lt;Zakim> RRSAgent, make logs Public<br>
&lt;Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference<br>
&lt;fantasai> florian: [first picture is clamping by line number, second is clamping by height]<br>
&lt;RRSAgent> I have made the request, Zakim<br>
&lt;fantasai> andreubotella: Another possibility is to not include float clearance in the sizing<br>
&lt;fantasai> andreubotella: the float would overflow the box essentially<br>
&lt;fantasai> andreubotella: That is a possibility that is easier than current behavior. I think that's what Firefox and WebKit do currently<br>
&lt;fantasai> andreubotella: This behavior is not what chromium does yet<br>
&lt;astearns> fantasai: so you’re saying we would size basedon the in-flow content only<br>
&lt;astearns> fantasai: the float would clip?<br>
&lt;astearns> fantasai: you’d want to clip it to the content edge of the box<br>
&lt;astearns> fantasai: would be reasonable<br>
&lt;fantasai> florian: So clip at that point, without needing to specify it<br>
&lt;fantasai> fantasai: Yes. In particular to content edge, not padding edge<br>
&lt;fantasai> astearns: You're saying this is what other engines do?<br>
&lt;fantasai> andreubotella: FF and WebKit have the float overflow.<br>
&lt;fantasai> florian: That's oversimplifications. Not just overflow but *everything* overflows and is visible, unless you make it hidden.<br>
&lt;fantasai> astearns: Do we have a quick resolution?<br>
&lt;fantasai> PROPOSED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.<br>
&lt;fantasai> andreubotella: Comfortable with resolving this for now. Unsure how to implement the clipping.<br>
&lt;fantasai> andreubotella: I suspect it won't be a blocker. Not opposed.<br>
&lt;fantasai> astearns: As you look into clipping to content edge, you can open up a new issue if you come up with something that makes more sense.<br>
&lt;fantasai> astearns: Any objections to proposed resolution?<br>
&lt;fantasai> RESOLVED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12665#issuecomment-3303665916 using your GitHub account


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

Received on Wednesday, 17 September 2025 16:03:49 UTC