[csswg-drafts] [css-overflow-4] line-clamp and decoration of interruped boxes (#12809)

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

== [css-overflow-4] line-clamp and decoration of interruped boxes ==
What should happen to the bottom decorations (margin, border, padding) of boxes interrupted by `line-clamp`? I'm specifically talking about descendants of the clamping container, not the clamping container itself.

[This example](https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=14064), applies `line-clamp: 4` (using the legacy syntax) to the following content.

> <img width="274" height="222" alt="2 lines of text, followed by 3 line aside with a green border and some padding, followed by a bit more text " src="https://github.com/user-attachments/assets/e042a4ef-8816-4349-96a8-0a5314ddfee4" />

Safari's legacy implementation:
> <img width="274" alt="Safari rendering, without a bottom border nor padding" src="https://github.com/user-attachments/assets/a48f07c7-55fa-4266-8766-e4998ff69fd3" />

Firefox and Chrome's legacy implementations:
> <img width="274" height="158" alt="Firefox/Chrome rendering, with a bottom border and padding, and content overlapping" src="https://github.com/user-attachments/assets/dcab57e6-6ec8-42f2-98f0-44a880db22a9" />

@andreubotella's experimental implementation based on the spec:
> <img width="274" height="152" alt="Andreu's implementation of the spec in Chromme, with a bottom border and padding, and no content overlapping" src="https://github.com/user-attachments/assets/c590dd05-4ac9-4302-8d2c-bb3e70c869b9" />

First, because legacy implementations differ, we are likely not constrained by compatibility. Then, Andreu's implementation, being based on clamp points rather than on `overflow: hidden`, is cleaner than the Firefox/Chrome implementation, which if you look closely have content bleeding over the retained padding/border.

But the more interesting difference is between @andreubotella's implementation and Safari. I'd argue that the Safari rendering (although achieved through a different underlying logic than the spec) is actually more desirable.
* Since the content is interrupted, having the bottom border/padding be interrupted too is a clear visual indication, in addition to the ellipse, that the content continues but is just hidden.
* We could leave this as a choice to authors, reusing the [`box-decoration-break` property](https://drafts.csswg.org/css-break-4/#break-decoration) as the switch. Slice-by-default, opt-in to clone would be consistent with the design of that property.
* If we do end-up pursuing `continue: discard` (or even `continue: fragment`) some day, it would be good to limit the divergences.

Based on this, my proposal would be that `box-decoration-break` takes effect on boxes that are descendants of clamping contexts (in addition to its current effects), and that when the value is `slice`, which is the default, If a [block container](https://drafts.csswg.org/css-display-4/#block-container) contains a [clamp point](https://drafts.csswg.org/css-overflow-4/#clamp-point), within itself or in any of its descendants, the used value of its block-end margin, border and padding are 0.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12809 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 08:23:09 UTC