- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 23:54:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-4] line-clamp and decoration of interruped boxes`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: this is a subissue of something we already discussed to see if we double down or change our mind<br> <TabAtkins> florian: if you start with a clamp container with a nested block element which has decorations, and we clamp in the middle of the decorated box, then what?<br> <TabAtkins> florian: first picture is no clamp. second picture is safari, it cuts the decoration. Firefox and chrome complete the decorations (and show some future lines peeking thru, probably a bug)<br> <TabAtkins> florian: currently the spec expects the decorations to be visible.<br> <TabAtkins> florian: safari doesn't seem to actually be doing clean slicing, this example is lucky.<br> <TabAtkins> iank_: this behavior is... we got bug reports from sites. ignoring the padding is how they clamp the intrinsic size<br> <TabAtkins> florian: I don't know if you got reports on the actual behavior (somewhat messy) or the slicing in the particular<br> <TabAtkins> florian: two things bother me about spec behavior<br> <TabAtkins> florian: first is we get mixed signals. ellipsis sign says something is continuing, bottom decoration signals it's done.<br> <TabAtkins> florian: in safari both signals point to unfinished, I thi8nk that's better<br> <TabAtkins> florian: in the future if we give authors a choice, the obvious property is box-decoration-break, and its default is slice, not clone<br> <miriam> q+<br> <TabAtkins> florian: even if we don't introduce the opt-in now, it would be nice to match the default<br> <astearns> personally I agree that slicing the decoration by default makes more sense<br> <dholbert> q+<br> <TabAtkins> florian: also want to add, we probably don't have great view for what authors actually want. current impls are buggy and inconsistent so people probably avoid decos anyway.<br> <emilio> q+<br> <iank_> q+<br> <andreubotella> q+<br> <TabAtkins> florian: spec says to clone the decorations. I think I prefer safari's behavior. what do we want?<br> <astearns> ack miriam<br> <TabAtkins> miriam: if I wanted Firefox/chrome's impl, or spec's impl, I would put the clamping on the decorated box instead.<br> <TabAtkins> miriam: I guess that's a bit different since I wouldn't be able to count the outside lines, but still<br> <astearns> ack dholbert<br> <TabAtkins> miriam: I would expect the default to be slicing like I get from multicol<br> <TabAtkins> dholbert: first, comparing the decos here, it's worth thinking about similar situation of inline with a deco<br> <TabAtkins> dholbert: in that case, if the ellipsis was in that span, the similar case would be slicing off the inline-end border.<br> <TabAtkins> florian: the ellipsis is nested directly in the para, not in the nested text, so if there is decos on inlines, that will never go around the ellipsis. it cuts before it.<br> <TabAtkins> dholbert: okay so if we did omit bottom border I think w'ed also want to decorate right border<br> <TabAtkins> florian: I think we do that, box-deco-break applies to inlines and slices by default<br> <TabAtkins> dholbert: second, box-deco-break seems... would clone give the bottom behavior (spec)?<br> <TabAtkins> dholbert: name's a little confusing, seems to make sense in fragmentation but still<br> <astearns> ack emilio<br> <TabAtkins> emilio: first, safari behavior is not what it looks<br> <TabAtkins> emilio: if you apply padding to the outer block, you'll see the decorated box is fully drawn actually. the slice is just lucky<br> <TabAtkins> emilio: I switched Gecko away from that behavior a while ago<br> <TabAtkins> emilio: second, this really only applies when the inner block has... this nested decorated block isn't too common<br> <TabAtkins> emilio: as soon as th einner thing has overflow:hidden or something, it doesn't work anymore (it's an IFC now)<br> <TabAtkins> emilio: so I'm not too sad about the spec beahvior<br> <TabAtkins> emilio: I think dholbert's point about box-deco-break makes this a bit less pressing.<br> <TabAtkins> emilio: if you want slice we could implement that, but it raises questions<br> <TabAtkins> emilio: we have line-clamp clamping the auto size, but yo u can still grow nad shrink. if you set height to one line, even though you clamp at 2, you'd probably expect the border to show? I dunno.<br> <TabAtkins> emilio: I think the behavior is fine. browsers all draw all the decorations in practice, WebKit just looks like it trims due to clipping<br> <TabAtkins> emilio: I expect this is edge-case enough that I don't think it's worth adding this special case where you only trim the decos if you're auto height<br> <TabAtkins> emilio: and you either make the decos not take space, like in Multicol, that's weird. what happens with the positions of the boxes under it?<br> <TabAtkins> emilio: I don't think you want to mess with layout. but if you don't mess with layout you can't remove the padding.<br> <TabAtkins> emilio: I think dholbert convinced me that b-d-b:clone is a bad opt-in. I think current spec beahvior is a good default, we can come up with another opt-in if we need.<br> <astearns> ack iank_<br> <bramus> q+<br> <TabAtkins> iank_: I think we should keep current spec<br> <TabAtkins> iank_: imagine you didn't have a border, just padding<br> <TabAtkins> iank_: and then border on the outer box. it starts to look weird because the border is right against the text, because the end padding is clipped<br> <TabAtkins> iank_: you can present test cases in either scenario that can look better<br> <TabAtkins> fantasai: in that example, say you have padding on the inner box and border on the out. if you have that, the spacing you have between the text and border is determined by that box.<br> <TabAtkins> fantasai: if you clone the padding on the inner box, you'll end up with *more* separation than what you actually wanted.<br> <TabAtkins> iank_: you're got, say, a background, and you want the padding to show that background<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14464<br> <TabAtkins> iank_: the other thing i'm concerned about is, when people have just created a wrapper, this'll change existing behavior. i'm concerned about that.<br> <TabAtkins> iank_: <lime-clamp><bordered-wrapper>text here...</></> <-- don't want to lose the bottom border just because it gets clamped halfway<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: clarifying spec about clamping<br> <TabAtkins> andreubotella: if you're clamping in a nested box...<br> <TabAtkins> andreubotella: the clamping happens in all of them. you pick the clamp point, then that innermost box is sized accordingly. its intrinsic size is reduced, then it's size is used to size the parent, etc<br> <TabAtkins> andreubotella: this means that if you're expecting the position of some element after the clamp point to be the same as when unclamped, that might not be true if you slice the border away<br> <TabAtkins> andreubotella: safari's legacy impl was large based on using overflow:hidden. dunno how we'll do something like that without something similar<br> <TabAtkins> florian: so to a first approximation, I think what we'd have here are that container block boxes of the lien that contains the ellipsis, are drawn and sized as if they have no bottom decoration. that's roughly right for slice behavior, right?<br> <TabAtkins> andreubotella: that's different from a Multicol case where the background continues to the next box...<br> <TabAtkins> florian: yeah a bit different from nested fragmentation<br> <iank_> and the simple wrapper case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14465<br> <TabAtkins> andreubotella: say you have a height, the background of the boxes won't continue<br> <TabAtkins> florian: which box?<br> <TabAtkins> andreubotella: line-clamp container with a height of 40px. the clamp is inside a nested box. if those boxes have background, they won't continue until 40px, they'll stop early.<br> <astearns> ack bramus<br> <TabAtkins> bramus: looking at examples, I think i'd prefer the bottom one<br> <TabAtkins> bramus: i'm looking at b-d-b, not clear if it's applying on outer div or inside<br> <TabAtkins> florian: b-d-b currently doesn't apply at all, that's for fragmentation and this isn't fragmentation. but it's *similar*<br> <TabAtkins> florian: so I think it would make sense to apply it, and if we did, it would apply on the children<br> <TabAtkins> bramus: alternative, we have overflow-clip-margin for defining the area outside of the clipped region that can still paint<br> <TabAtkins> florian: we don't need to change anything spec-wise to get the bottom behavior, that's already there. we would to get the top, which I prefer, but other people disagree.<br> <dholbert> Note, the issue with the top edges of the next line's characters still-drawing is sort-of intended; emilio landed a patch to make us not paint those lines ( https://bugzilla.mozilla.org/show_bug.cgi?id=1791226#c2 ) but we had to revert it because it turns out some sites including LinkedIn depend on us painting that overflowing content (in cases where they shift it up into view) ( https://bugzilla.mozilla.org/show_bug.cgi?id=1934547 )<br> <TabAtkins> astearns: I also somewhat prefer the top option (slice), but it's definitely an edge case and I don't care very much.<br> <TabAtkins> florian: i'm not too concerned about the switch now, I just think we're making it hard to switch later, so I was hoping we could switch the default to match the likely switch<br> <TabAtkins> emilio: that's a concern if we do want to use b-d-b to do the switch, but I don't think we want that<br> <TabAtkins> emilio: so if we want a different switch, the default behavior is less of a concern so long as it's reasoanble<br> <TabAtkins> astearns: so we have differing opinions on the default, some concerns about particular switches but it's likely we can design one<br> <TabAtkins> florian: we also seem to have impl consensus that the bottom behavior is easier<br> <TabAtkins> emilio: for sure<br> <astearns> ack fantasai<br> <TabAtkins> iank_: and some mild compat concern for anything besides bottom<br> <TabAtkins> fantasai: adding yet another switch for controlling how to slice boxes, I think it's great for authors. it's already a weird small thing people don't usually think about.<br> <TabAtkins> fantasai: so if we need a switch i'd really like b-d-b. if we need to add an "auto" initial value we can do that<br> <fantasai> s/great/not great/<br> <TabAtkins> andreubotella: also with continue:discard we considered adding an additional longhand set with line-clamp that would be a signal to set b-d-b<br> <TabAtkins> florian: I suspect it's easier to just add a new "auto" initial value...<br> <TabAtkins> emilio: it's been in use for a while, but it's rare. we could probably get away with changing initial value.<br> <TabAtkins> astearns: i'm not hearing consensus with making changes today. should probably keep the spec as-is unless we get strong author feedback about changing default or needing a switch<br> <TabAtkins> florian: do we feel like closing the issue until someone comes with something, or leave it open as an anchor?<br> <TabAtkins> astearns: either is fine with me. you opened the issue.<br> <TabAtkins> florian: until we're at pub/rec time where open issues bother us, I'd rather keep it open<br> <TabAtkins> astearns: so no resolution, but keep issue open and see if we can get author feedback<br> <TabAtkins> dholbert: I can also explain the Firefox behavior. it's kinda on purpose<br> <TabAtkins> emilio: we should update our behavior to match the spec tho<br> <TabAtkins> dholbert: okay, never mind<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12809#issuecomment-3808168279 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 January 2026 23:54:11 UTC