- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Mar 2026 16:22:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Fragmenting (`continue: collapse`) line-clamp containers``, and agreed to the following: * `RESOLVED: we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> andreubotella: How do we handle a line-clamp container in a fragmentation context, like multicol<br> <TabAtkins> andreubotella: browsers differ, sometimes broken<br> <TabAtkins> andreubotella: also, what should happen when the line-clamp container itself has columns/etc<br> <TabAtkins> andreubotella: I think if we want to make them fragment, wk's behavior is what we'd want<br> <TabAtkins> andreubotella: You just slice the line-clamp container into fragments. the co9unt is preserved across the fragment break, and the height is the total height including the slice gap<br> <TabAtkins> andreubotella: this is WK's current -webkit-line-clamp behavior.<br> <TabAtkins> andreubotella: for clamping by height, they don't currently support it by defualt<br> <TabAtkins> andreubotella: also, overflow:hidden, which is used everywhere in webkit-line-clamp as its a required property there<br> <TabAtkins> andreubotella: depending on browser, it can make the box model different<br> <florian> q+<br> <TabAtkins> andreubotella: with line-clamp you don't need that overflow, but maybe we should make it automatically make the content monolithic<br> <TabAtkins> andreubotella: chromium does that by default, except when you set columns on the actual line-clamp container<br> <TabAtkins> andreubotella: (which seems to be a bug)<br> <TabAtkins> andreubotella: in WebKit where you're slicing the result into multiple columns, this is relatively easy to do<br> <TabAtkins> andreubotella: main problem is taking into account the gap between columns when clamping by height<br> <TabAtkins> andreubotella: but in engines where it fragments it's more complicated<br> <TabAtkins> andreubotella: so, should we allow this? what to do about it?<br> <emilio> q+<br> <TabAtkins> andreubotella: there's also a question - if you have display:block or flow-root the columns proeprties works, but not -webkit-box or float.<br> <astearns> ack florian<br> <emilio> I think we resolved on it happening at computed value time? So it should apply per spec I think<br> <TabAtkins> florian: when it comes to 'column' applying directly to a clamp container, not sure when we took a resolution but I think we did take one that says it won't apply<br> <TabAtkins> florian: the original draft for continue:discard explicitly worked with Multicol and the new value changes that<br> <TabAtkins> florian: so I think we did make a decision at some point and we should probably stick with it<br> <TabAtkins> florian: when instead it is *in* a fragmentainer i'd prefer fragmenting properly. i'd be okay with monolithic, don't see much use-cases there. would be sad about slicing in the middle of a line.<br> <TabAtkins> florian: can you reexplain WebKit behavior?<br> <TabAtkins> andreubotella: visually it behaves as fragmenting properly. but the layout engine basically does it in one single fragment, leaving the gap, then slices<br> <TabAtkins> florian: okay so it looks like it's fragmenting properly, that's fine<br> <TabAtkins> andreubotella: in layout engines that do it "properly" it's just a bi tmore complicated, is why I mentioned it<br> <TabAtkins> andreubotella: you need to keep track of the gaps and ...<br> <TabAtkins> andreubotella: when clamping by height you're not sure if you clamp until you've started working on the next fragment. that's a bit more complicated<br> <astearns> ack emilio<br> <TabAtkins> florian: it seems better to do the full fragment, but use-cases dont' seem strong. so if the monolithic beahvior is simpler that's ok by me<br> <TabAtkins> emilio: I agree monolithic is simpler<br> <TabAtkins> emilio: per spec, we resolve on -webkit-box to flow-root fixup to happen at computed value time, and it seems clear what happens there<br> <TabAtkins> florian: we could make an exception if we wanted to...<br> <TabAtkins> emilio: sure but why would we<br> <TabAtkins> andreubotella: if you agree that's what the spec implies, that's probably correct<br> <TabAtkins> andreubotella: I wasn't 100% sure<br> <astearns> ack fantasai<br> <TabAtkins> astearns: let's table that aspect for now, you can raise an issue if it turns out to still be important. want to concentrate on line-calmp containers in a fragment context<br> <TabAtkins> fantasai: I agree with florian that we should fragment properly<br> <TabAtkins> fantasai: don't have a strong opinion on a line-clamp that is also fragment context<br> <TabAtkins> fantasai: but *in* in a fragment context should do correctly, counting across the whole thing<br> <TabAtkins> fantasai: you just have to walk backwards when counting<br> <TabAtkins> emilio: our fragment breaks are always after a line... ok<br> <TabAtkins> emilio: it should be well-defined in terms of line count<br> <emilio> q+<br> <TabAtkins> astearns: so it sounds like we're converging on "properly" fragmenting line-clamp containers, taking wk's impl as a guide<br> <TabAtkins> andreubotella: in layout engines like chromium that's a bit harder. at the point where you're doing layout on the second fragment you can't modify the first anymore<br> <TabAtkins> andreubotella: so you'd have to make sure the clamp won't happen in the first frag<br> <TabAtkins> andreubotella: so more complicated but doable<br> <TabAtkins> emilio: I think was gonna suggest similar<br> <TabAtkins> emilio: if you grow the block past the clamp point, which you can by setting the height to a tall number, you can end in a situation where the clamp is in the previous fragment, line -1 basically<br> <TabAtkins> emilio: should be fine to treat it as zero or something. maybe a bit weird<br> <TabAtkins> emilio: but I think it's not a common use-case ,shoudln't matter much<br> <TabAtkins> astearns: proposed then, we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go<br> <TabAtkins> astearns: do we want a resolution on a line-calmp container that *is* a Multicol, or a separate issue?<br> <TabAtkins> florian: if anyone wants to argue it should apply... currently spec says it doesn't and i'm okay with that<br> <TabAtkins> (I think it's reasonable to forbid it, seems weird)<br> <TabAtkins> astearns: hearing no one calling for it, we'll leave it as specified<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12812#issuecomment-4040424779 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 March 2026 16:22:16 UTC